Date: Thu, 2 Mar 1995 23:47:43 -0500 From: Rich Martin <rmartin@TIAC.NET> Subject: A little storyHere's a little story I thought I should share with the list. The problem described is somewhat interesting in itself, but the methods by which I conquered it are probably more informative.
I recently authored a kiosk application of goodly size on the Macintosh which was contracted to see delivery on a Windows platform. The client's products were being displayed throughout, so careful attention to color fidelity was required. This meant creating 36 custom palettes, each sharing 16 base colors for the screen's background. Early testing seemed to prove that Director for Windows offered as much freedom with multiple custom palettes as the Mac version and that one could afford to disrespect the 20 Windows interface colors in a standalone kiosk with no ill effect. So intense graphics production began on the Mac, using Photoshop to prepare the screens and Debabelizer to manage the custom palettes. Lingo programming was done in parallel, using scratch graphics to implement a prototype which would provide all the interactivity and functionality of the final product. After all the pieces were assembled into a completed program, it was migrated to the Windows machine for final tweaking before the initial client review. So far so good - this was a well planned and executed project and all the early testing made for a smooth transition between platforms.
Except for one spot where there were problems. The palettes got screwed up. One palette from another part of the program got 'stuck' and remained in effect until the program was restarted. Arrgh! Everything had worked fine on the Mac, and I'm not the power user I usually am when my machine runs Windows rather than Mac OS. I double-checked my puppetPalettes again. Everything was done by the book. I had yielded control back to the score by calling 'puppetPalette 0' at the proper times. I then verified that all the (hundreds of) graphic elements were the proper colordepth and assigned to the appropriate palettes. I started using belt-and-suspenders techniques, inserting redundant 'puppetPalette' commands into the Lingo, and redundant palette changes into the Palette channel. Still no success. There was something about one branch of the program that ruined the palette control.
I tried eliminating the Palette channel from the score, and delegating *all* palette control to Lingo using 'puppetPalette' commands instead. I tried eliminating all 'puppetPalette' commands and keeping all palette changes in the Palette channel. Then I began to suspect the hardware. Knowing that all Windows video display cards are not created equal, I dug into the SYSTEM.INI file, looking for some magic switch which would get the monitor to change palettes when requested. I swapped out the display card, trying another which had been a proven winner. The problem remained. I suspected out-of-memory conditions, or some arbitrary limit on the number of palettes or palette changes. These theories proved no more fruitful than their predecessors.
My colleagues were both patient and sympathetic, offering advice and encouragement, but I was getting exasperated. I was sure that they had already concluded what I was reluctantly beginning to admit to myself - perhaps I'm not the hotshot Director wizard I pretend to be. But wizard or not, I *am* stubborn enough to doggedly track the problem until it is found. I pressed onward, despite my growing despair and impending madness. I knew that something was happening in one particular branch of the program which was hosing my palettes. I suspected it was some renegade graphic or palette manipulation. I *would* find it or die in the attempt!
For the umpteenth time, I had to answer the question - "Getting anywhere on that palette problem, Rich?" - with another frustrated "Not at all". My exasperation got the best of me, and I began to demonstrate my various attempts by deleting entire sections of the score and cast wholesale - each deletion left the problem intact. But I realized suddenly that I was on to something. I stopped trying to fix the problem and began trying to destroy it. Eventually I would delete the offending item and then it would be isolated and identified. Section after section of the score was sacrificed. As long as the palette problem persisted, I knew that I could focus on a smaller and smaller collection of suspects.
And at last the offending item stood out. It had been right in front of me all the time, and why I gave it no thought remains a mystery to this day. It has been my habit when coding Lingo to write "dummy" routines to hold the place of "real code" until it becomes reasonable to code the handler properly. So that the unfinished work does not go unnoticed, I usually insert an 'alert' command which states what the dummy routine will do once it is finished. And indeed, in this project, one dummy routine remains. I clicked the "OK" button of that alert hundreds of times - each time cursing the client for not telling me what I should do at that point - but never realizing that the alert box itself was **The Offending Graphic**. That innocuous window was a Windows system element, yearning deeply for its familiar but missing interface colors! It should have been obvious from the start. This was the only item appearing on the screen which I had not crafted with my own hands.
On the Macintosh, the onscreen appearance of an alert box has no adverse effect on custom palettes. But on a Windows machine, it has the effect of terminating Director's ability to control custom palettes entirely, via Lingo or the Palette channel. Arrgh!
____________________________________________________________________
rmartin@luddites.tiac.net Lingo programmer for hire | Not |
__________________________________________________________| Insane! |
http://www.tiac.net/users/rmartin |_________|