May 2002 - Wine-Devel - list.winehq.org

menu behaviour on window losing focus

by Rizsanyi Zsolt

Hi! Now that my patch to fix the alt behaviour made to the cvs (altough somewhat cleaned up by Alexandre :), I'm going on to fix what remained here to fix :) The problem is that when you activate the menu (by pressing ALT), and then the window loses focus, the menu stays active. And when you return to your window the menu still has focus. This is not right for two reasons: 1) This is not the windows behaviour - on windows when the window loses focus the menu is deactivated. I have tested this. The same is the behaviour with kde. 2) When you switch beetween windows by Alt+TAB sometimes the menu stays active. It does not happen so frequently, but it is annoying. So I would like to deactivate the menu when the window loses focus. Can somebody please point me to the point in code where I should put my deactivation (a code which is called on window deactivation), and also to the function by which I can deactivate the menu. If nobody answers, I will try to find these myself, but I have thought, that maybe there is somebody who can answer these questions in no time. Thanks in advance Zsolt Rizsanyi

May 2, 2002

RE: Ftruncate check

by Steven Edwards

> Well I don't think that > > #define ftruncate(fd, size) > > is a good replacement for ftruncate <g> > > You'll either have to implement ftruncate in mingw, or change > makedep to not require it. But making it silently broken is > not a good idea. Ok. I got that from http://developer.gnome.org/doc/API/glib/glib-windows-compatability-funct ions.html and it works under mingw but I will try to find a better way of doing it or just fix makedep. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

May 1, 2002

Re: Ftruncate check

by Alexandre Julliard

"Steven Edwards" <Steven_Ed4153(a)yahoo.com> writes: > I saw it was not applied. What was wrong with it? Well I don't think that #define ftruncate(fd, size) is a good replacement for ftruncate <g> You'll either have to implement ftruncate in mingw, or change makedep to not require it. But making it silently broken is not a good idea. -- Alexandre Julliard julliard(a)winehq.com

May 1, 2002

statusbar question

by Medland, Bill

I am about to have a go at tidying up a little problem with the statusbar and our application and I want to check as to what we really know and what we are currently guessing. Our application has a sunken owner-drawn part in the status bar, in which we draw multiple icons. Under WINE the part is not sunken (and the icons are poorly rendered - a separate issue) but the background colour is OK. I see that currently the code for statusbar is: For all parts If owner drawn then let the owner draw it else fill the background if ownerdrawn then let the owner draw it (legacy code) else draw the border if there is an icon then draw it draw the text. fi fi end for Can anyone justify this order as opposed to e.g. draw the background, draw the border, then if owner drawn let the owner draw the rest, otherwise draw the icon and text? It seems to me that the latter is more consistant with what I see but I don't want to break a load of stuff. Bill

May 1, 2002

Re: WM_PAINT BUG

by Dustin Navea

--- ziolas <ziolas11(a)poczta.onet.pl> wrote: > Well I've been trying to get UT and DeusEx to work > under winex 2.0 (yeah I > know about the linux binaries for UT). It both work > great under software > rendering but in HW they suck. In D3D the game loads > up, then complains about > vertex buffer and shuts down. In opengl it doesn't > display any 3d graphics > (ex. in deus ex I can see the menu, but not the 3d > logo behind it), and the > console is flooded with "beginpaint not called on > WM_PAINT" messages. This is > probably a bug which should be fixed. Good luck to > the winex devel's! > this message is probably better suited to the winex forums, but let me take a look at it and see whats up, be right back __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com

May 1, 2002

RE: MAX_PATH mess fix

by Steven Edwards

> IMO it's a mingw problem, stdlib.h is not supposed to define > MAX_PATH, only _MAX_PATH. Ok thanks, I'll go bug them for a while. Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

May 1, 2002

Ftruncate check

by Steven Edwards

I saw it was not applied. What was wrong with it? Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

May 1, 2002

Re: MAX_PATH mess fix

by Alexandre Julliard

"Steven Edwards" <Steven_Ed4153(a)yahoo.com> writes: > Is this a mingw problem? If so I wil go talk to them, if not then it > just needs > This before the MAX_PATH define. IMO it's a mingw problem, stdlib.h is not supposed to define MAX_PATH, only _MAX_PATH. -- Alexandre Julliard julliard(a)winehq.com

May 1, 2002

RE: MAX_PATH mess fix

by Steven Edwards

> I have committed a different fix that I think should work > too, please give it a try. We should be 100% > Windows-compatible now so if it still doesn't work I'd say > the problem is in Mingw. > Your fix worked for all of the missing MAX_PATH errors in winnls.h and wingdi.h but I still get one warning every once and a while. ../include/windef.h:155: warning: `MAX_PATH' redefined /usr/include/mingw/stdlib.h:62: warning: this is the location of the previous de finition Is this a mingw problem? If so I wil go talk to them, if not then it just needs This before the MAX_PATH define. #ifdef __MINGW__ #undef MAX_PATH #endif /* __MINGW__ */ In any case I can live with this warning now that the errors are gone. Thanks For the help so far. Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

May 1, 2002

Java and Wine Interoperability on Solaris

by Warren_Baird＠cimmetry.com

Hi all, I've got an interesting problem on my hands - I need to invoke some winelib compiled win32 code from java (though jni) on a sparc-solaris box. Unfortunately I'm running into problems with the libthread.so library. If I create the JVM (which involves loading libthread.so) before wine, I get a segfault in the wine process_init function (during a call to getcwd that works its way down into libthread). If I instead initialize wine first, and then dlopen libthread.so and try to create the JVM, I get a segfault in the JVM code, in a function who's name includes the word thread (if that actually means anything). I've seen a few indications on the mailing list and in the docs that wine is not compatible with pthreads, but I haven't found a concrete discussion that gets into a lot of details - if anyone knows of a document somewhere that talks about this, I'd love to see it. I notice that there is a pthread.c file in scheduler, that seems to implement part of the pthreads api in terms of wine threads for glibc. Does anyone know if it would be possible to get something similar working on solaris? Does anyone have any other suggestions on how I might be able to make this work? Thanks! Warren

May 1, 2002