RE: win32libs
- Posted by Matthew Lewis <matthewwalkerlewis at YAHOO.COM> Mar 14, 2001
- 485 views
> -----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