Open Letter on the Dialog Manager

By Kirk Chase, Editor

To the Developer Community

Rodney K. Magnuson

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

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

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.

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.