lansd@utgpu.UUCP (10/04/87)
I have several questions about DA under Mark Williams C (Ver 2.1.7): 1) The MWC manual under 'desk accessories' mentions that 'malloc()' should not be used in a DA. Why? Can I use Malloc() instead? I presently use malloc() in the main() of the DA - do they mean not to use malloc() in the DA loop where it actually performs its function, instead of the main() initilization part? 2) When a window is open when I call up my DA, a weird thing happens when a dialog is removed from the screen that it puts up. The sequence is... a) Desk accesory is started b) DA saved the screen to buffer c) A large dialog is put up on screen d) User invoked action causes File selector (or some other) dialog to be called up on top of the main dialog. e) The new sub-dialog saves the screen in a 2nd buffer. f) Dialog/file-selector is handled and returns to the DA ok. g) The DA dumps the screen buffer back to the screen (ok). h) *** PROBLEM *** After the main dialog has been redrawn from the screen buffer and calls form_do() once again to get the next user object hit, GEM comes along and places its window OVER TOP of my main dialog!!!! Only the screen area that the sub-dialog covered is updated. WHY IS GEM DOING THIS???? I know it occurs when form_do() is called. Do I have to remove all messages from the AES message array before I call form_do() again? (but I can't call evnt_multi() to pick them up). 3) For the program version of my DA, the sliders work fine. But on the DA the followng happens: a) Pressing the button over the slider (which calls graf_slidebox) shows the slider change into a graf_slidebox outlined box then hangs. b) Pressing the button over the left or right arrows (TOUCHEXIT buttons) returns to my program on the button press, but does not return to my program while the button is being held down c) If the left button is pressed, the first press is registered by my program but the second button press SELECTS THE GARBAGE CAN ICON UNDER THE DIALOG (and displays it OVER the dialog). These problems show that by calling form_do() the DA is relinquishing control to the other application running (the desktop). I know that GEM is switching between the two applications on each call, but HOW DO I PREVENT THESE PROBLEMS FROM HAPPENING? <Robert Lansdale>
jafischer@lion.waterloo.edu (Jonathan A. Fischer) (10/04/87)
>... lansd@gpu.utcs.toronto.edu (Robert Lansdale) writes: > I have several questions about DA under Mark Williams C (Ver 2.1.7): > >1) The MWC manual under 'desk accessories' mentions that 'malloc()' should >not be used in a DA. Why? Can I use Malloc() instead? This is because of a bug in GEM which doesn't free the memory malloc'ed by the DA when there is a resolution change. When the user changes resolution, the DA is started from scratch again, so it mallocs another chunk, leaving a hole where the last chunk was malloc'ed. The problem of using .RSC files with DAs is related. Rsrc_load() Mallocs memory, so resolution changes cause the same loss of memory. Solution: if the area you need is under 64K, just create a static variable. (Too bad MWC didn't remove that limitation with this release). Otherwise, ... well, any suggestions? >2) When a window is open when I call up my DA, a weird thing happens when >a dialog is removed from the screen that it puts up. The sequence is... > > ... described dialog box problem. As well as things under the > dialog box being activated when mouse clicks over them. One suggestion (probably won't solve _all_ your problems) is to make sure you're calling wind_update(BEG_UPDATE) before starting up your dialog box. (And, of course, don't forget to call wind_update(END_UPDATE) afterwards!) You could also open a window around your area of interaction. This should lock that area of the screen to your application, I believe. However, using the wind_update() calls is guaranteed to be much safer. You see, if you're running an accessory that _doesn't_ freeze the other applications, you're left at the other programmers' mercy. And I've found that not even half of the GEM programs I've used perform things like window redraws correctly. Even commercial programs! For instance, CAD 3-D 2.0 will redraw its slider bars for the 4 CAD windows over any window opened by an accessory whenever CAD gets a redraw message. And most of the public domain accessories out there simply redraw their whole area when they get a redraw message. You know, programming in GEM is an incredible effort, it seems to me. And then half of the stuff you do doesn't seem to work right the first time, so you have to root through everything you may have saved from two years' worth of Compuserve (in my case) and the Net. Then you look through the Abacus book, except you can't really trust that. So you buy the Balma/Fitler "Programmer's Guide to GEM," and find that it kind of glosses over the particular area of GEM that you're working on, (and it only mentions about 50% of the VDI calls). Oh yeah, Tim Oren's Pro- fessional GEM series. Doesn't quite cover what you want. Aha! Try the new Mark Williams documentation. It's pretty helpful. And wasn't there some source sitting around on one of your disks that gave an example of just what you wanted to do? Yep. So you finally get that particular aspect of GEM going, and can go on to the next. Except, geez, that bloody public domain desk accessory blithely ignores the rules of the game and messes up your screen. Oh well, absolutely nothing you can do about that. *Sigh* And by the time we thoroughly understand GEM (bugs and all), the '020 and '030 machines (and the '386 machines) will be so cheap we'll buy them and won't need to know GEM anymore. I can certainly speak for myself that as soon as I graduate (and pay off all the student loans my wife and I have chalked up...), I'll be buying a new computer, and it won't be a Mega. It would be nice if Atari's '020 machine (which, as we all know, is imminent) would be GEM compatible, but as far as I know, Atari only has a binary license and not a source license. And DRI certainly won't port GEM, if my past impressions of DRI hold true. -- - Jonathan A. Fischer jafischer@lion.waterloo.edu