🚀 go-pugleaf

>... 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