Well this was an interesting one that took the entire w/e to solve!
The following problem appears to have been caused by the display of one of
my progress messages in the midst of drawing a table cell (see the 'Fixed!
Was: How to display a 'progress' type of form in 3.5' thread for more
info.). For some reason, the draw window is not being restored upon having
displayed a progress window, despite having called FrmSetActiveForm. Thus,
I've modified the progress window logic to look something like this:
*****
mDrawWinH = ::WinGetDrawWindow();
mActiveFormP = ::FrmGetActiveForm();
mFormSentry = FrmDeleteFormSentry(::FrmInitForm(inFormID));
::FrmSetActiveForm(mFormSentry.Get());
::FrmDrawForm(mFormSentry.Get());
... do some stuff
mFormSentry = FrmDeleteFormSentry(0); // Calls FrmEraseForm and
FrmDeleteForm
if (mActiveFormP)
::FrmSetActiveForm(mActiveFormP);
if (mDrawWinH)
::WinSetDrawWindow(mDrawWinH);
*****
The above logic appears to work and I shall know for certain when I get
past about 500K gremlins in the next 24 hours. There is definitely a value
for mActiveFormP and so FrmSetActiveForm does get called. If I don't have
the WinSetDrawWindow after though, things go wonky.
This solution confirms my belief that FrmSetActiveForm is selectively
calling upon WinSetDrawWindow and WinSetActiveWindow in OS 3.5 (please
refer to the 'PalmOS 3.5 discoveries' thread for more information). In OS
3.0 it just calls them.
Any confirmation of my observations and comment on my solutions would be
most welcome.
Incidentally, if you're wondering why I'm displaying a progress window
while drawing a table: when I get records in Teenee (my C++ application
framework) I cache them. Updates of the cache can occur all over the
place. One such instance is where the cache is flushed to make way for a
new record; this was the case in my redraw situation. When the cache is
going to take a noticeable amount of time, I display a message to keep
friendly. :-)
Kind regards,
Christopher
Christopher Hunt wrote:
> Its me again!
>
> After about 250,000 gremlins under OS 3.5 debug, I get a bus error with
> the following debugger log:
>
> Remote stopped due to: BUS ERROR EXCEPTION
> 'WinEraseRectangle'
> +$0014 10C56D20 *MOVE.L $001A(A3),A2
> | 246B 001A
> sc
> Current UI App stack: size = #3536, amount never used = #1052
> Calling chain using A6 Links:
> A6 Frame Frame Size Caller
> 0001B89A #0000000060 10C69800 FrmDispatchEvent+0046
> 0001B87E #0000000028 10C65E6C PrvSendEventToForm+0024
> 0001B866 #0000000024 100426F6 HandleEvent__Q3611General+0070
> 0001B84E #0000000024 10041E3A HandleEvent__Q2612EventHa+0040
> 0001B832 #0000000028 100427C0 DoHandleEvent__Q3611Gener+007C
> 0001B812 #0000000032 10C667E6 FrmDrawForm+0156
> 0001B7D4 #0000000062 10C7689E TblDrawTable+0018
> 0001B7C6 #0000000014 10C756F4 DrawTable+019C
> 0001B776 #0000000080 10C7510E DrawItem+00B2
> 0001B738 #0000000062 10C56D20 WinEraseRectangle+0014
>
> I know there's been a little discussion on this forum recently
> concerning WinEraseRectangle ('Re: WinEraseRectangle and PalmOS 3.5'),
> but as you can see, FrmDrawForm is being called; from within a
> frmOpenEvent handler (DoHandleEvent__Q3611Gener+007C). Thus a
> frmLoadEvent would have occurred prior where FrmInitForm,
> FrmSetActiveForm and FrmSetEventHandler would have been called.
>
> I've also seen the bus error appear for other times where
> WinEraseRectangle has been called. I see that the code for DrawItem has
> changed since OS 3.0 and so I don't know why WinEraseRectangle is being
> called or where a bus error could occur in WinEraseRectangle.
>
> Any ideas?
>
> My build environment is:
>
> * MacOS;
> * the OS 3.0 API; and
> * CW R5 (no patches given integration with Pro 4).
>
> I'm really at a bit of a loss so any help would be most appreciated.
--
Christopher Hunt
Class Action Pty. Ltd.
Complete time zone management for the Palm(tm) connected organizer.
Check out http://www.classactionpl.com/
---
For information on using the Palm Developer Forums, or to unsubscribe, please see
<http://www.palm.com/devzone/mailinglists.html>.
