Re: Dialog painting
On Mon, Sep 17, 2001 at 11:33:03PM +, Gerard Patel wrote: Your code does not display anything because no message is retrieved from the message queue. After the Sleep call, WM_PAINT messages are available, but as you don't retrieve them by calling PeekMessage or something like that, nothing is shown. Ok, I see. I actually did compare the messages sent in windows to those sent in wine and then I noticed, among other things, that no WM_PAINT messages were received in this case. I don't want to say that your app code is wrong, of course. It may very well be, but it works with real windows and some apps use constructs like this (and exhibit the same problems in wine). There is a problem in Wine, but I don't know what to do about it. My first thought would be to scan the X queue and retrieve the expose events as was done before the great changes of this summer, but this may be somewhat difficult to do right. Well, the window needs to be painted during the first call to CreateDialog() - how to fix it is another matter. My naive idea would be to just set the invalid region manually and/or to send a WM_PAINT. Fetching expose events may also be a good idea, but I know very little about the interaction between Wine and X so I can't really say whether that is a good or a bad idea. I prefer to waste my time searching for other problems, because I have no doubt that Alexandre Julliard is aware of this one and it's clear that he is not finished yet with X code reorganization. Ok, thanks for clueing me in. Nicke -- -[ [EMAIL PROTECTED] ]- Seek simplicity, and distrust it. (A. Whitehead)
Re: GDI object refcount?
Well, if you can implement this, then just go ahead. Just remember that you have to do the refcount increase/decrease in every single SelectObject function. On the other hand I think I know more about that at the moment ;) So if you don't want to do it, then I'll do. Hmm. I think it would be nice if you could do it :) As you said, you seem to know your way around that code way better than me. Nicke -- -[ [EMAIL PROTECTED] ]- Seek simplicity, and distrust it. (A. Whitehead)
Dialogs and SetParent()
Hi I've found a really simple application with exhibits strange behaviour. I'm no Win**ws programmer, so I don't know if the code is ok, but at least it seems to be. I wrote it while trying to debug some problems with a resource editor called Resource Hacker 2.2.1. I'm using the 20001026 release of Wine. The attached (6k) archive includes source and exe of a small program which opens a window and a dialog and calls SetParent() to make the dialog a child of the window. For debugging purposes, clicking in the main window flips the dialog on/off. Note that the dialog already was a child from the beginning, so one would think that the SetParent() call shouldn't change much? Problems under Wine: - the dialog can't be dragged. - the dialog isn't painted properly in unmanaged/managed modes. Desktop paints ok. Observations: Calling SetParent() makes the dialog "clipped into" the main window. It behaves more or less like WS_CHILD would get set IMHO, but GetWindowLong returns nothing special, so no flags apparently change in real win95. Setting WS_CHILD in SetParent() appears to fix the dragging problem, but I'm not sure if it is the right thing to do. I wonder how win95 does this. --- win.c_bak Mon Oct 30 23:54:01 2000 +++ win.c Thu Nov 2 01:08:21 2000 @@ -2408,6 +2408,7 @@ if(!(wndPtr = WIN_FindWndPtr(hwndChild))) return 0; dwStyle = wndPtr-dwStyle; + wndPtr-dwStyle |= WS_CHILD; /* FIXME: Hack */ pWndNewParent = hwndNewParent ? WIN_FindWndPtr(hwndNewParent) : WIN_LockWndPtr(pWndDesktop); I really have no clues regarding the painting problems, but I have a feeling that the same bug causes problems with the playlist editor in my rather old version of Winamp as well. That one is also done using a dialog. Any input is appreciated. Nicke -- -[ [EMAIL PROTECTED] ]- Seek simplicity, and distrust it. (A. Whitehead) ZIP archive
Debugger problem
Hello. For quite some time I've been having problems attaching winedbg to a running process, for instance in the case of automatic invokation due to a crash. Direct invokation causes no problems and I also believe that my registry entries are all ok. My kernel is a standard 2.0.34 which otherwise has caused no problems and I use glibc 2.0.7 (yep, my system is oldish). I've traced the problem to this: debug_process() in server/debugger.c sets an error code which makes the debugger abort. To be more precise, this error code is set due to the call to get_thread_ip() == get_thread_context() which in turn calls: ptrace( PTRACE_GETREGS, pid, 0, regs ) Now, this call fails for me with a EIO, so it seems like my system doesn't like PTRACE_GETREGS, at least according to the manpage? Did I miss anything, or can it really be the case? Are there any workarounds for this apart from just resetting the error code, which isn't very nice but gets the debugger going? How about a configure check or a error message for this? Should I prepare myself mentally for a system upgrade? ;-) Nicke -- -[ [EMAIL PROTECTED] ]- Seek simplicity, and distrust it. (A. Whitehead)
