App works almost perfectly, but one MDI screen won't draw
Installing my company's app is still a bear -- the only way I've found to avoid the dreaded "object reference not set" is to run with --debugmsg +ole and redirect to a file (not to the screen, and not to /dev/null). Once installed, the app runs quite well... except for one screen, which remains nearly blank. The MDI frames draw fine, but the contents (which include a hex memory dump area and a tree control) remain blank. Since there were a few richtext fixmes, I threw in native richtext dlls, and that got rid of lots of fixmes, but didn't help the display. Here's the Wine log file, passed through uniq -c: 1 fixme:win32:PE_CreateModule Security directory ignored 1 err:win32:PE_fixup_imports No implementation for WSOCK32.dll.1141 imported from blahblah.dll, setting to 0xdeadbeef 1 fixme:ole:CoRegisterMessageFilter stub 1 fixme:commdlg:GetFileName95 Flags 0x00800002 not yet implemented 1 fixme:winsock:WS_bind Setting WS_SO_REUSEADDR on socket before we binding it 2 fixme:mdi:MDIRefreshMenu partially function stub 1 fixme:dc:LockWindowUpdate ((nil)), partial stub! 3 fixme:mdi:MDIRefreshMenu partially function stub 1 fixme:winsock:WS_bind Setting WS_SO_REUSEADDR on socket before we binding it 8 fixme:mdi:MDIRefreshMenu partially function stub 1 fixme:ole:CoRegisterMessageFilter stub Grr. Nothing's really obvious to this non-windows-programmer, and the guy who wrote this program is on vacation, so I can't pick his brains. Anyone have suggestions for what to try next? Thanks, Dan p.s. FWIW, here's sort | uniq -c of the log file before I threw in the native DLLs: 1 err:win32:PE_fixup_imports No implementation for WSOCK32.dll.1141 imported from blahblah.dll, setting to 0xdeadbeef 1 fixme:dc:LockWindowUpdate ((nil)), partial stub! 9 fixme:mdi:MDIRefreshMenu partially function stub 2 fixme:ole:CoRegisterMessageFilter stub 1 fixme:richedit:RICHED32_WindowProc Unknown message 0x24 Passed to default hwnd=0x110023, wParam=00000000, lParam=40791e18 622 fixme:richedit:RICHED32_WindowProc Unknown message 0x363 Passed to default hwnd=0x110023, wParam=00000001, lParam=00000000 1 fixme:win32:PE_CreateModule Security directory ignored 2 fixme:winsock:WS_bind Setting WS_SO_REUSEADDR on socket before we binding it
Dan Kegel wrote:
Installing my company's app is still a bear -- the only way I've found to avoid the dreaded "object reference not set" is to run with --debugmsg +ole and redirect to a file (not to the screen, and not to /dev/null).
Once installed, the app runs quite well... except for one screen, which remains nearly blank. The MDI frames draw fine, but the contents (which include a hex memory dump area and a tree control) remain blank.
I was going to spend this weekend fixing another MDI app to fix a draw problem that several exhibit (for example, Kaleidegraph). Oddly it is just the opposite; the contents draw ok but not the frames. I already have a good idea of where the problem on them is. Would a demo version of your app be available for download somewhere? I would be interested in testing it.
Could you explain this to me please? I tried Kaleidograph and started looking at why the "Demo version only" dialog that pops up at the beginning wasn't blanking the background properly, which I decided was because the app didn't call BeginPaint but I am very much a novice. So, if you could explain how you tracked down these bugs I'd very much appreciate it! thanks -mike On Wed, 2003-01-22 at 02:15, Duane Clark wrote:
Dan Kegel wrote:
Installing my company's app is still a bear -- the only way I've found to avoid the dreaded "object reference not set" is to run with --debugmsg +ole and redirect to a file (not to the screen, and not to /dev/null).
Once installed, the app runs quite well... except for one screen, which remains nearly blank. The MDI frames draw fine, but the contents (which include a hex memory dump area and a tree control) remain blank.
I was going to spend this weekend fixing another MDI app to fix a draw problem that several exhibit (for example, Kaleidegraph). Oddly it is just the opposite; the contents draw ok but not the frames. I already have a good idea of where the problem on them is.
Would a demo version of your app be available for download somewhere? I would be interested in testing it.
-- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
Mike Hearn wrote:
Could you explain this to me please? I tried Kaleidograph and started looking at why the "Demo version only" dialog that pops up at the beginning wasn't blanking the background properly, which I decided was because the app didn't call BeginPaint but I am very much a novice.
So, if you could explain how you tracked down these bugs I'd very much appreciate it!
I ran the app under WinNT and Wine, and compared the messages generated using SPY++. There are non-client (border) and background fill messages missing. So then it becomes a matter of figuring out where they should be generated. Otherwise in the case of Kaleidagraph, there is an additional problem where GetMenuItemInfoA is called with invalid parameters, causing crashes. I temporarily hacked around that, and KGraph then seems to work quite well for me (though I did not test extensively). It is a bit of a mystery to me why the call is bad; it is a call directly from the app. I wonder if the wrong function is being called for some reason. But that is something I will look into later.
Duane Clark wrote:
I ran the app under WinNT and Wine, and compared the messages generated using SPY++. There are non-client (border) and background fill messages missing. So then it becomes a matter of figuring out where they should be generated.
Maybe I'll try that on my bad app, thanks for pointing out the obvious! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
So then it becomes a matter of figuring out where they should be generated.
Yeah, that's the big that usually gets me :) Are they the sort of messages that should be generated by Wine or the app? What happens if the app doesn't call BeginPaint in a WM_PAINT handler. Is that an API violation, or are there reasons for it? MSDN had an explanation that seemed to suggest that in certain unusual circumstances you didn't need to call it, but I don't remember exactly what.
It is a bit of a mystery to me why the call is bad; it is a call directly from the app. I wonder if the wrong function is being called for some reason. But that is something I will look into later.
How common is it for apps to actually make bad API calls? QuickTime seemed to do that, is it rare or not? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
Mike Hearn wrote:
So then it becomes a matter of figuring out where they should be generated.
Yeah, that's the big that usually gets me :) Are they the sort of messages that should be generated by Wine or the app?
By Wine. In general, I have found message bugs relatively straightforward to fix.
What happens if the app doesn't call BeginPaint in a WM_PAINT handler. Is that an API violation, or are there reasons for it? MSDN had an explanation that seemed to suggest that in certain unusual circumstances you didn't need to call it, but I don't remember exactly what.
Yea, I want to try to figure out the exceptions and add something to silence those messages. In this case, they appear to be a "red herring". Looking at SPY++, the WM_NCPAINT and WM_ERASEBACKGROUND messages should have been sent prior to posting the WM_PAINT message. But more studying to come.
It is a bit of a mystery to me why the call is bad; it is a call directly from the app. I wonder if the wrong function is being called for some reason. But that is something I will look into later.
How common is it for apps to actually make bad API calls? QuickTime seemed to do that, is it rare or not?
I don't really know. From the looks of this one, I cannot believe the app was written this incorrectly, so the bug must be something more subtle. I think I am going to have to resort to disassembling the small portion of the app that makes the call to figure out what is happening. Fortunately, the location shows up just fine in winedbg when it crashes, so that makes things easier.
This is from a +message,+relay trace - surely this cannot be right? Just before this in the trace that same window proc generates lots of calls in response to a WM_NCPAINT message, so why might it not be generating any calls at all for ERASEBKGND? trace:message:SPY_EnterMessage (0x2007e) L"Main" message [0014] WM_ERASEBKGND sent from self wp=000012ec lp=00000000 08078250:Call window proc 0x988cce (hwnd=0x2007e,msg=WM_ERASEBKGND,wp=000012ec,lp=00000000) 08078250:Ret window proc 0x988cce (hwnd=0x2007e,msg=WM_ERASEBKGND,wp=000012ec,lp=00000000) retval=00000001 trace:message:SPY_ExitMessage (0x2007e) L"Main" message [0014] WM_ERASEBKGND returned 00000001 (is there any way to stop evolution wrapping the text?) This is from a toolbar in XMLSpy, the BCGToolBar MFC control, so I expect it overrides all kinds of things. The buttons draw OK, but the surrounding area doesn't get redrawn, so the toolbar handle and the parts around and in between the buttons are damaged. Is that simply due to the background not getting erased, or is it due to an invalidation bug do you think? I tried with Spy++ and the message order seems correct, a fairly standard paint->ncpaint->erasebkgnd sequence. Any ideas? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
Duane Clark wrote:
Mike Hearn wrote:
Could you explain this to me please? I tried Kaleidograph and started looking at why the "Demo version only" dialog that pops up at the beginning wasn't blanking the background properly, which I decided was because the app didn't call BeginPaint but I am very much a novice.
So, if you could explain how you tracked down these bugs I'd very much appreciate it!
I ran the app under WinNT and Wine, and compared the messages generated using SPY++. There are non-client (border) and background fill messages missing. So then it becomes a matter of figuring out where they should be generated.
That sounds like the problem my app is having, too. Now that I have Spyxx.exe running, I see that a WM_NCPAINT message is sent to that window in WinMe but not in Wine. Interestingly, a WM_NCPAINT *does* get sent to the parent window ("AfxFrameOrView42") in wine. Is it supposed to percolate down from that to its child area? - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Dan Kegel wrote:
That sounds like the problem my app is having, too. Now that I have Spyxx.exe running, I see that a WM_NCPAINT message is sent to that window in WinMe but not in Wine.
NC messages affect the border that Windows (and Wine) add to a window. The border that you use to stretch or move the window, and that contains the window title. Since your problem is within the window client (content) area, it is probably unrelated.
Interestingly, a WM_NCPAINT *does* get sent to the parent window ("AfxFrameOrView42") in wine. Is it supposed to percolate down from that to its child area? - Dan
Generally, no they won't percolate. I am most of the way through a fix for the WM_NCPAINT messages in MDI apps, so that will probably come out this coming weekend. It turned out that finding where the fix went was fairly easy, but actually implementing it was slightly trickier than I expected.
On Tue, 2003-01-21 at 20:15, Duane Clark wrote:
Dan Kegel wrote:
Installing my company's app is still a bear -- the only way I've found to avoid the dreaded "object reference not set" is to run with --debugmsg +ole and redirect to a file (not to the screen, and not to /dev/null).
Once installed, the app runs quite well... except for one screen, which remains nearly blank. The MDI frames draw fine, but the contents (which include a hex memory dump area and a tree control) remain blank.
Visual Foxpro (Thanks for the patch Duane!) does the same thing with 'Wait Windows'. With a relay trace, it runs slow enough that you can see the text is actually drawn (using gdi32.ExtTextOutA) but is then overwritten by the window itself.
I was going to spend this weekend fixing another MDI app to fix a draw problem that several exhibit (for example, Kaleidegraph). Oddly it is just the opposite; the contents draw ok but not the frames. I already have a good idea of where the problem on them is.
Would a demo version of your app be available for download somewhere? I would be interested in testing it.
If Dan's app behaves the same as mine, I can create a prog that displays a window :) FWIW, Transgaming's current CVS WILL display the text correctly, but what appeared to be an MDI window is actually created unmanaged (with windows decorations). If anything, that's one way to test and see if you get your text.. Rick
Rick Romero wrote:
If Dan's app behaves the same as mine, I can create a prog that displays a window :)
FWIW, Transgaming's current CVS WILL display the text correctly, but what appeared to be an MDI window is actually created unmanaged (with windows decorations). If anything, that's one way to test and see if you get your text..
Please do send me a test app. I plan on going after several painting bugs for the next few weekends.
participants (5)
-
Dan Kegel -
Dan Kegel -
Duane Clark -
Mike Hearn -
Rick Romero