RE: win32libs

new topic     » goto parent     » topic index » view thread      » older message » newer message

> -----Original Message-----
> From: Wolf [mailto:wolfritz at KING.IGS.NET]
> 
> I've got two demo's in this zip.
> One, written for win32lib version 0.55.1, GPF's frequently, 
> on *closing*.
> The other, re-written for version 0.51, *never* seems to do this....
> ..darn !!!
> Tests, and feedback, appreciated.

I used another bitmap, and it worked fine, unless I moved/resized the window
several times.  Then I got the GPF.  I tracked it down to tk_mem.e.  It was
real easy to find using the translator:

tk_mem.e:116            VOID = c_func(xHeapFree,{ pHeap, 0, pAddress}) 

Rob, how about adding a trace feature like this to the interpreter?  Maybe
trace(2) could direct all trace output to ctrace.out or something.  Ex.err
works fine for normal Eu errors, but tracking down GPF's, especially in
win32lib, can be very difficult.

I'm not terribly familiar with tk_mem's guts, so I think I'll ask Derek to
take a look.  I can't figure out why this would happen.

Using this technique, I located the point at which I've had GPF trouble
(once again, on closing).
I tracked it down to SubProc.  The crash happens when a TabControl gets a
WM_NOTIFY with an LVN_DELETEALLITEMS notification.  This happens when the
app is closed, and when there is a ListView with a TabControl as parent.  I
added this code to SubProc right above the call to xCallWindowProc:

if window_type[id] = TabControl and iMsg = WM_NOTIFY then
    VOID = fetch( lParam, NMHDR_code )
    if VOID = LVN_DELETEALLITEMS then
        return popSelf()
    end if
end if

For some reason, the tab control can't handle this message, but this
prevents a GPF.

Matt Lewis

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu