This is the one that was put in the auto_scroll branch of the CVS, when I
was doing it (the reason was that the play/stop button also would redraw to
the menu, since there would be a pen down over the pixel area of a top
toolbar bitmap, and toolbar bitmaps have to stop the autoscroll). Therefore,
came across this bug at the same time, so tried to work out one thing to
solve them all. What was done was an active window check. For the hardkey
press reuse, I think it called this function to check to see what window is
active before letting a button start drawing. If the main viewport is active
then it will draw, if it isn't (ie the menu or something else like a hack
popup is active window), then it won't. Hardkeys aren't relevant on any form
other than the mainwindow anyways.:
Boolean MainFormWinActive()
{
FormType* mainForm;
mainForm = FrmGetFormPtr( Prefs()->toolbar );
if ( WinGetActiveWindow() == FrmGetWindowHandle( mainForm ) )
return true;
else
return false;
}
An exanded out, more readable version (and less memory if it is written out,
apparently) rewrite of this from Michael is:
Boolean MainFormWinActive()
{
FormType* mainForm;
WinHandle mainWindow;
WinHandle activeWindow;
mainForm = FrmGetFormPtr( Prefs()->toolbar );
mainWindow = FrmGetWindowHandle( mainForm );
activeWindow = WinGetActiveWindow();
if ( mainWindow == activeWindow )
return true;
else
return false;
}
Note that one could theoretically just look at the attr->visible, of the
menu, this is out since it won't work in OS 5.0, since not allowed access to
structures anymore.
Palm seems to recommend (if I recall correctly) putting a handler into what
would be our viewer.c that catches every single window enter and exit events
and carry an overhead of tracking that, but I don't know if that will drag
down our execution speed as we move around the forms.
> I used to use PalmTelnet with my GPS to debug the communications
> (before Palm decided to change the port and clip-on design on me,
> making my
> two Rand McNally GPS units useless, thank you Palm),
That is rough. Palm has been pretty good to the software developers (giving
the ROM images well in advance, support free toolchain), but on the hardware
end, not too helpful.
> > For draw windows, there was another (and probably rarer!) bug that was
> > related, that if one is viewing a full scale (pannable) image in the
> > viewer, and enter the command shortcut to change the toolbar from top to
> > bottom, the viewer will go down with a fatal crash.
> In my opinion, which differs from Mike's, a crash is a bug, no
> matter how rare the situation or circumstances that can cause it
> to happen.
> This is why we have gremlins.
Sounds reasonable. I think a !LargeImage() check before moving the toolbar
top to bottom would be enough (and if it is a LargeImage(), then go back to
the mainform and move the toolbar), but there may be more to it than that.
Best wishes, Robert
