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

Re: toolbar.c problem

by Duane Clark

Rick Romero wrote: > > Forgive the intrusion, but I've been watching your thread, because it > sounds quite like bug # 434. > http://bugs.codeweavers.com/long_list.cgi?buglist=434 My own feeling is that this probably is not related, because my patch was pretty specific to mouse up events within the toolbar. The WM_LBUTTONUP message that you refer to in this bug is sent from many different routines, depending on where the mouse is in the app. Also, this bug appears to be a problem of a missing mouse capture release. In my case, the cursor was being released just fine. It was just that the expected action was never invoked. > > I believe it was your toolbar.c patch that initially fixed the toolbar > issues, but out of curiosity, before the patch, were you able to check > if it was a regression? (Maybe back to 6/20/01?) I found your comments( > http://www.winehq.com/hypermail/wine-devel/2002/03/0109.html ), but I > didn't see any comments indicating a regression test. My memory of events that far back is vague, but my recollection is that the toolbar problem with my two apps (fpga_editor and Designer) has been there since I started using wine, about May 2000. There were indeed a number of other regressions triggered by the June 2001 changes, so I do remember that date fairly well ;) > I think what you described is happening in other areas (see the bug), > with other apps, but for your app, it only manifested in the toolbars. Possible, but I suspect just a coincidence. The TOOLBAR_LButtonUp() routine should only be called very specifically when the mouse is in the toolbar. It certainly is possible that there is a very similar problem in another routine, though.

April 23, 2002

Re: minor regression testing patch

by Geoffrey Hausheer

> but, MS's documentation: > http://msdn.microsoft.com/library/en-us/sysinfo/sysinfo_49iw.asp > suggests something more like: > > #define WIN98_PLUS(version) \ > ( (version.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS) && \ > ( (version.dwMajorVersion > 4) || \ > (version.dwMajorVersion==4 && version.dwMinorVersion>0))) > > Is this more correct? I don't think so. If you look at my test, you'll see that I explicitly check for WIN98+ OR Win2k+ (that is, for some functions, the only valid operating systems are Win2k, Winxp, win98, and winme. The code above would allow nt4.0 in there too. The following link is how I defined the macros: http://msdn.microsoft.com/library/en-us/sysinfo/sysinfo_3a0i.asp For instance, GetLongPathName is only defined for Win2k and later an Win98 and later (thus no NT4.0): http://msdn.microsoft.com/library/en-us/fileio/filesio_2cv9.asp Is something in the test causing a failure? I've tested them on win2k and win98 (the only real Microsoft OS that I have access too) Thanks, .Geoff

April 23, 2002

Re: toolbar.c problem

by Rick Romero

On Fri, 2002-04-19 at 13:14, Dusan Vujosevic wrote: > > ----- Original Message ----- > From: "Duane Clark" <dclark(a)akamail.com> > To: <wine-devel(a)winehq.com> > Sent: Friday, April 19, 2002 11:41 AM > Subject: Re: toolbar.c problem (ATTN: Duane) > > > > I think you misunderstood my explanation. Once the menu is stuck and the > > button released, I slide the mouse into the flying menu and back out > > again, without pressing any mouse buttons. When the cursor leaves the > > flying menu, it disappears, but without calling TOOLBAR_LButtonUp(). > > This is the second behavior, which may not be related. > > I am working with the latest build of SL and this doesn't happen. I guess > you have the demo and that it does have that problem in which case it is > irrelevant since it has been fixed. > > > >>Unfortunately > > >>for me, my real work is once again interfering severely with the amount > > >>of time I have to spend on Wine :-( > > > > > > > > > I'd be all too happy to help. I will take off my own time to test & fix > > > this. I'll try give you something over the weekend (patch). > > > > > > > > >> But I will try to get in a couple > > >>of tests with ControlSpy with the TBSTYLE_DROPDOWN style, since it > > >>should not take much time, perhaps this weekend. > > > > A suggestion I made a couple weeks ago would make things easier, I would > > think. That would be to duplicate your flying menus within ControlSpy. I > > don't know how easy that would be to implement, but once implemented, it > > would likely make debugging much easier. > > OK, that's what I'll do. I will implement it (not a big deal) and forward it > to you. Expect it this weekend some time.. > > Thanks, > Dusan > Forgive the intrusion, but I've been watching your thread, because it sounds quite like bug # 434. http://bugs.codeweavers.com/long_list.cgi?buglist=434 I believe it was your toolbar.c patch that initially fixed the toolbar issues, but out of curiosity, before the patch, were you able to check if it was a regression? (Maybe back to 6/20/01?) I found your comments( http://www.winehq.com/hypermail/wine-devel/2002/03/0109.html ), but I didn't see any comments indicating a regression test. I think what you described is happening in other areas (see the bug), with other apps, but for your app, it only manifested in the toolbars. Rick

April 23, 2002

Re: fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

by Laurent Pinchart

> > >Just wanted to say the winpos.c.diff patch of 12/25/2001 works like a charm >for me. > [...] > >Thanks Laurent! > You're welcome :-) BTW, why hasn't this patch been commited to CVS ? I submitted twice and never got any feedback before today. Laurent Pinchart

April 23, 2002

existing cooperation with mono?

by Freddy BL

Hi Wine-Team! Existing cooperations between the Wine-project and the Mono-project (http://www.go-mono.org)? At the moment it seams, that in the future there exists under MS-Windows three types of programs: programs which are in native-code (that can be run on Wine and can be portet to Linux by re-compiling with Wine), programs which are in MS-IL-code (that can in the future be run on Mono I hope) and mixed programs (IL-Code-programs, which integrate Native-Code DLLs and Native-Code-programs, which integrate IL-Code DLLs). And I think, that for the last type of programs a cooperation between the Wine-Devels and the Mono-Devels is very advantageous. So, existing this cooperations? (One of the results of an coopration could be an installer like that by CodeWeavers, which can be install both (Wine and Mono) for example) Greatings Freddy BL _________________________________________________________________ Senden und empfangen Sie Hotmail über Ihr Mobilgerät: http://mobile.msn.com

April 23, 2002

Re: Unit testing

by Francois Gouget

Hi Jakob, Jakob Eriksson wrote: > > Is there a tutorial or so for how to create > new unit tests in Wine? Well, not really. The closest thing is the presentation I gave at WineConf2002: http://www.codeweavers.com/about/news/talks/wineconf2002/regression/ Writing proper documentation for the regression framework is part of the Wine 0.9.0 tasklist: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=526 > If not, I'll just go ahead and use those there are for blueprints. Combined with a quick walk through my presentation, this should pretty much get you up to speed :-) -- Francois Gouget fgouget(a)codeweavers.com

April 23, 2002

Re: fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

by David Yerger

Just wanted to say the winpos.c.diff patch of 12/25/2001 works like a charm for me. [Was my first experience actually building wine from source - took me about two days to figure out how to patch an SRPM and build the patched version. Apparently what you're supposed to do is put the patch in the SOURCES folder, modify the spec file, run rpm -bb <specfile> and let it rip. Had no success doing rpm -bp wine.spec, patching manually and then running configure manually, or using tools/wineconfig, and then running rpm -bi --short-circuit or make install - I could build the program but it complained when I tried to run it. Sorry, I thought I wrote down the complaint. . . Oh well, I'm pretty sure it's because of something I did wrong anyway.] Thanks Laurent! David Yerger

April 23, 2002

Re: Please educate me

by leanne

Medland, Bill wrote: >Can anyone explain what is going on here please; this is obviously an area >of bash etc I don't understand. > >This morning I was doing a fresh install on a totally clean machine from the >Wine-20020411 tarball under Redhat 7.1. > >All went reasonable well until I saw a "..<something not write> .." go >flashing past as I ran wineinstall and later on the regapi failed because it >couldn't find libntdll.dll.so. OK so I guess it was the ldconfig that >failed!! > sorry and do not know I could help. when I got "libntdll.dll.so no such file..." I add a line "/usr/local/lib" in /etc/ld.so.conf and then run "ldconfig" (I guess u install in the default path /usr/local/...) > > >So I thought "lets fix it". Yes; in the last fix to wineinstall where we >went with using "su root" instead the ldconfig was hard-coded (and wasn't on >the path for simply "su root"). So I followed up on the machine I normally >use and started messing about with $ac_cv_path_LDCONFIG. I got that >working, consistant on hand-editing the config.cache to change "true" to >"/sbin/ldconfig". > >So the remaining thing was to get the cache entry generated correctly. This >is where the problem is. (I still don't understand why it should get set >either to the name of an executable or to the value "true"; I dislike >variables holding dissimilar types). Anyway I was watching the loop so see >why it wasn't finding the /sbin/ldconfig and I noticed that > >for ac_dir in /sbin:/usr/sbin:$PATH > >was splitting as >1. /sbin:/usr/sbin:/usr/local/bin >2. /bin >3. /usr/bin >etc. > >Now, I know I can force it to work by changing the for loop to >for ac_dir in /sbin /usr/sbin $PATH > >However the original form used to work (I guess, since the cache is correct >on my other machine) so I'd rather know why it isn't working currently and >fix that > >Can anyone explain why it isn't splitting the for the way we want it to > >TIA > >Bill >

April 23, 2002

Re: Enhancements and fixes for the rich text edit control

by Alexandre Julliard

ccrayne(a)crayne.org writes: > Because of this concept, it was necessay to make two small changes to > edit.c -- to move the definition of the EDITSTATE structure into (new > file) edit.h, and to add support in function EDIT_BuildLineDefs_ML to > recognize "\n" as an alternative soft line break. I don't think richedit should know about edit.c internal structures (and it seems your patch didn't require that anyway) so I haven't applied that part of the patch. If we really need to access the internal edit structure it will have to be made Windows-compatible so that we can still mix builtin and native dlls. But it's better to avoid it if possible. -- Alexandre Julliard julliard(a)winehq.com

April 22, 2002

Re: dlls/kernel/comm.c build failure

by Gil Kloepfer Jr.

I think I probably need to get on the mailing list, but... On Mon, Apr 22, 2002 at 08:46:03AM +0200, Gerald Pfeifer wrote: > The following patch > > revision 1.56 > date: 2002/04/21 22:06:09; author: julliard; state: Exp; lines: +24 -0 > <wine(a)gc2.kloepfer.org> > Faster serial speed cases for non Linux systems. > > broke dlls/kernel/comm.c on FreeBSD 4.5 (and probably all non-Linux > systems) The 57600 and up case (even for Linux) didn't have the CBR_ prefix before them, which is why I didn't have them in the patch I sent to Bugzilla. I compiled the changes I submitted successfully on FreeBSD 4.5-RELEASE, so it should have worked OK. I'll admit to being a newbie at the entire innards of Wine, so I may have misunderstood something. But the code inside the "CBAUD" (I assume this is what Linux uses) #ifdef has all baud rates >38400 without the CBR_ prefix in the switch statement. I simply copied this same set of case statements to the non-CBAUD version (the #elif !defined(__EMX__) case) and changed the port.c_cflag to port.c_ospeed. Hope this helps explain my thought processes. It looks like that whole pair of switch/case/#ifdef statements is screaming for a bit of simplification. (PS: I'll try to cc the mailing lists, but if it doesn't make it, would someone please forward it along ... thanks) --- Gil Kloepfer wine(a)gc2.kloepfer.org

April 22, 2002