Jul 91 Letters
Volume Number: 7
Issue Number: 7
Column Tag: Letters
Open Letter on the Dialog Manager 
By Kirk Chase, Editor
To the Developer Community
Rodney K. Magnuson
Leonard Development Group
With the incarnation of System 6.0.4, the Dialog Manager has not been handling
purgeable dialog resources correctly. And it has become worse with 6.0.5, 6.0.6, and
6.0.7.
What this means is that any application you have developed that contains
purgeable PICTs, cicns, WDEFs, dctbs, and others used as dialog items will now bomb
under tight memory conditions when purging is necessary. I have sent a couple of links
to DTS on the matter and the following reply explains their attitude towards the issue.
------
The dialog manager NEVER handled purgeable resource correctly. The dialog
manager was designed to handle small and specific cases in controlled situations. This
was probably a mistake in the very first version, since it is guaranteed that, given a
large pool of developers, there will be some that push it to/beyond its limits.
The problem is that the dialog manager is a most convenient thing. There are
some dialog items, such as TextEdit items, that are a real pain to use if you are not
using the dialog manager. I can understand the reluctance to use a regular window,
when the dialog manager takes care of such stuff.
Given that the dialog manager has always been this way, I don’t expect that it will
get fixed anytime soon. I am just stating opinion here, but I do have a good amount of
history to back me on this one.
What can you do about it? Well, one thought is that you could write a routine
that walks the DITL and makes the resources non-purgeable. Once you are done with
the dialog, you could walk the DITL again and once again make them purgeable. This
would make using the dialog manager in these instances completely safe.
Another solution is to not use the dialog manager at all. You mentioned using
MacApp to accomplish this. You could do it this way, but you can also not use the dialog
manager and not use MacApp at the same time.
Along this approach, I have recently written a TextEdit control. With a single
call, you can add a TextEdit control to a regular window. This control can be read/write
or-read only. It can have a horizontal and/or vertical scrollbar. Scroll is
automatically taken care of. Drag-selecting as well. You can set a limit to the number
of characters that can be inserted. It has code to update the edit menu to reflect
selection choices and whether or not something is in the clipboard. It is a complete
implementation. I am currently using it in a 7.0 AppleEvents sample that I wrote and
it is working just great. I can send it to you if you are interested.
Given such alternative methods, which are actually better than using the dialog
manager, it is hard to justify continuing to use the dialog manager, when the
work-around code necessary to use it is larger than alternative implementation
methods.
------
Is Apple’s recommending not to use the Dialog Manager because it’s buggy? Is
Apple’s telling me to use MacApp or do the same thing that MacApp does, just to
overcome the bugs in the Dialog Manager? This to me is irresponsible! What about all
of the applications that people use every day? Should the users of these applications
upgrade their applications, when and if the developer ever gets an update out, so that
they will not bomb? Should the users of these applications use systems earlier than
6.0.4? If this is the answer, than Classic, LC, and SI owners are trouble. I would say
the answer is 6.0.8. Apple needs to address this problem! Are they hoping that
everyone is going to use 7.0? What are they thinking?
I wonder if Mr. Sculley knows about this, because he should. End users are
experiencing more bombs. And bombs should be caused, if they should ever occur, by
applications (well, I guess I should say INITs, since they are the main scapegoat these
days). I guess it’s the developer’s fault for using the dialog manager/pushing it beyond
its limits. What’ll go next? The menu manager?
I want to note that the respondent tries to help, I mean him/her no harm in my
response. I would also like to see an article on his TextEdit control. [I would be very
interested to see it, too-ed]
TMON Professional
ICOM Simulations
648 S. Wheeling Road
Wheeling, IL 60090
(708) 520-4440
ICOM Simulations has announced the release of TMON Professional, their latest
version of monitor/debugger for the Macintosh. TMON Professional is listed at $249
or a $100 upgrade to registered users who send in their original TMON disks. TMON
Professional is a multi-window monitor/debugger that allows you to view all heap
zones, even in MultiFinder. You can add menu items that correspond to TMON functions.
A new feature allows you to view the resource map of any open file letting you track
resources more carefully. TMON Professional supports Discipline and dcmds, 68XXX,
32-bit memory management, and color. And their are a host of other features.
32-Bit QuickDraw
Lawrence D’Oliveiro
Hamilton, New Zealand
I read in the February issue with great interest as usual (for some reason, it
arrived almost simultaneously with the January and March issues), but I was quite
perplexed by Hugh Fisher’s article “Colorizing the Mac”. It seems to me much of his
hard work was completely unnecessary.
According to my documentation for 32-Bit QuickDarw, that software add-on
includes (among other things) a great many enhancements to the Palette Manager. In
particular, it is possible to set up the colour table for an off-screen PixMap so that
CopyBits will map the pixels to animating entries in the window palette-which would
have solved Hugh’s problem!
How do you do this? St bit 14 in the ctFlags field of the off-screen CLUT. Then,
in the “value” field of each ctTable entry, put the index of the palette entry which is
mapped to the corresponding source pixel value. That is, if a pixel in the source PixMap
has the value x, then ctTable[x].value specifies the palette entry to be used for drawing
the pixel on the screen.
In short, you don’t need 16- or 32-bit-per-pixel display hardware to take
advantage of many of the capabilities of 32-Bit QuickDraw. Among its other features
are
• Enhancements to the Palette Manager, as already mentioned. These also include
the ability to control precisely which palette entries take effect in which screen
modes, so that you can ensure that your display looks the best at whatever mode the
user chooses.
• Easy creation and manipulation off off-screen PixMaps of any depth (1, 2, 4, 8,
16 or 32 bits per pixel) and with any set of colours you choose, regardless of the
settings or capabilities of your actual display hardware.
• An option to perform error diffusion when displaying, say, a 32-bit-per-pixel
image on an 8-bit screen. This option sacrifices some of the fine detail-giving
you a slightly grainier picture-in order to display a truer rendition of the
original colours of the image.
32-Bit QuickDraw has been the official release since about the middle of 1989,
and has been bundled with system software since System 6.0.5. It’s built in to the ROM
of all colour-capable Macs beginning with the IIci (that is, the IIci, IIfx, IIsi and LC).
On models older than this (the II, IIx, IIcx, and SE/30), the cost of installing the
add-on is only about 100K of RAM.
I suspect a lot of people believe that, unless you’ve got a display that can show
thousands or millions of colours, it’s not worth bothering with 32-Bit QuickDraw. I
hope the above point will convince a few people otherwise.
I agree 32-Bit QuickDraw appears to be a bit of a “pot-pourri” of all kinds of
functionality. In particular, the documentation doesn’t make it clear whether the
useful new function BitMapToRegion--which doesn’t have anything to do with colour at
all!--is available on black-and-white Macs. Also, it would have been nice if the
Palette Manager enhancements, at least, could have been made available as an ordinary
System patch. This could appeal to some people with older Macs, who think that the
RAM overhead of installing the whole 32-Bit QuickDraw is a bit too much.
Another point that Hugh makes, that I must take issue with, is his assertion that
“the Palette Manager is present on all Macs” (including non-colour-capable ones). It
can’t be.
The Toolbox trap table on black-and-white Macs has room for 512 entries,
allowing you (or rather, Apple) to define trapes in the range $A800 to $A9FF. The
colour-capable Macs have 1024 entries in their Toolbox trap tables, allowing them to
have the additional traps $AA00 to $ABFF. If you check the interface files, you’ll see
that all the Color QuickDraw and 32-Bit QuickDraw traps (with the notable exceptions
of BitMapToRegion and the Color Picker Package) are in the latter range. Any attempt
to call (or use GetTrapAddress on) an upper-range trap on a non-colour-capable
machine will give you one of the lower 512 traps instead--for example, attempting to
call or determine the address of NewPalette ($AA91) will get you LineTo ($A891) and
so on. On a black-and-white machine, the trap dispatcher effectively ignores the
setting of bit 9.
I found this out the hard way. I used to check if a machine supported colour by
seeing if the OpenCPort trap was defined. Then I ran my code on an SE under System
6.0.7. Result--crash! The reason, of course, was that my GetTrapAddress call on
OpenCPort ($AA00) was returning the address of the new 6.0.7 SndDispatch trap
($A800) instead.
On The UserLand Frontier
Userland Software, Inc.
490 California Ave.
Palo Alto, CA 94306
(415) 325-5700
Userland has announced their plans to ship UserLand Frontier in October of this
year. You may recall that Userland beat Apple to the inter-application communication
punch by releasing UserLand IAC Toolkit; this product allowed IAC applications to be
developed for both System 6 and System 7. Frontier will do the same in the OS
scripting capabilities.
Frontier is a scripting system that will allow for “batch” type operations that
have been sorely needed in the interactive windowing world. Applications can now take
advantage of IAC by providing an interface to scripting services such as Frontier. This
will allow control of applications such as Finder, databases, or yours through a script
(programming language). For example, a script might be set up to back up your hard
disk or send files over a modem without user action.
Frontier takes an outlining approach to scripting. This allows the scripter to
hide the details of a handler or a structure so he can see the overall flow of the script
(makes you wish you could do the same in your editor so you could hide all the details of
procedures you are finished with). Source level debugging is also available, as well as
an intelligent object database for script variables. A QuickScript feature is also
included which can act like a command line interpreter.