wine-devel

wine-devel@winehq.org

84463 discussions

Re: [PROBLEM REPORT] Focus problem for mdi children
by Michael Cardenas 30 Nov '01

30 Nov '01

*Doesn't this fix the problem in Word where if you have multiple documents open and you switch between them, you can't use the menu bar any longer?* ------------------------------------------------------------------------------- * From:* Alexandre Julliard (/ julliard(a)winehq.com/ <mailto:julliard@winehq.com?Subject=Re:%20%5BPROBLEM%20REPORT%5D%20Focus%20problem%20for%20mdi%20children&In-Reply-To=%3C87wv129jiq.fsf@mail.wine.dyndns.org%3E> ) *Date:* Wed Nov 07 2001 - 19:46:37 EST * ** Gerard Patel <gerard.patel(a)nerim.net <mailto:gerard.patel@nerim.net?Subject=Re:%20%5BPROBLEM%20REPORT%5D%20Focus%20problem%20for%20mdi%20children&In-Reply-To=%3C87wv129jiq.fsf@mail.wine.dyndns.org%3E>> writes: > Using this patch : > --- winpos.c.orig Wed Nov 7 10:41:32 2001 > +++ winpos.c Thu Nov 8 00:44:29 2001 > @@ -955,7 +955,20 @@ > ShowCaret(winpos->hwnd); > } > > - if (!(winpos->flags & SWP_NOACTIVATE)) SetActiveWindow( winpos->hwnd ); > + if (!(winpos->flags & SWP_NOACTIVATE)) > + { > + SetActiveWindow( winpos->hwnd ); > + if (!(wndPtr = WIN_FindWndPtr(winpos->hwnd))) return FALSE; > + > + /* child windows get WM_CHILDACTIVATE message */ > + if( (wndPtr->dwStyle & (WS_CHILD | WS_POPUP)) == WS_CHILD ) > + { > + WIN_ReleaseWndPtr(wndPtr); > + SendMessageA(winpos->hwnd, WM_CHILDACTIVATE, 0, 0L); > + } > + else > + WIN_ReleaseWndPtr(wndPtr); > + } > > /* And last, send the WM_WINDOWPOSCHANGED message */ > > > seems to fix the problem. It may be too simple though :-) No actually it's pretty much the right thing. I have applied a slightly simplified version of your patch, thanks for the report. -- Alexandre Julliard julliard(a)winehq.com <mailto:julliard@winehq.com?Subject=Re:%20%5BPROBLEM%20REPORT%5D%20Focus%20problem%20for%20mdi%20children&In-Reply-To=%3C87wv129jiq.fsf@mail.wine.dyndns.org%3E> -- //------------------------------------------ Michael Cardenas Software Engineer Lindows.com, Inc. http://www.lindows.com 858-410-5950 619-972-8153 //------------------------------------------- --

1 0

Is there a good reason why we ...
by Bill Medland 29 Nov '01

29 Nov '01

I've just tripped over this again which reminded me to ask why we do it. Is there a good reason why we have to specify the full correct path to a dll in the dll overrides section if it isn't in the windows system? A program runs at some location on the path. It uses a dll which is in the same directory. I want explicitly to use a winelib builtin "dll" instead of it. I can't simply say "a4wwine"="builtin"; I have to use the full path. That would cause problems if the exe and dll moved. Is there a good reason for this behaviour? (i.e. would it be a waste of my time changing the dll override stuff?) Bill

1 0

FoxPro 5 Applications
by Rick Romero 29 Nov '01

29 Nov '01

Hello, I've been attempting to get Foxpro 5 applications running for a while now. Actually, I just download from cvs randomly, and see what happens. It's been a while, but I decided to try again in October. At that time, there was an OLE error, but the only other strange occurance was a 'locking' of the screen on a print preview. Since then, this 'locking' is the only issue (though I havn't yet attempted to print). The apps I'm trying are my own, basically just a form is called, the user puts in a date range, and a report is run. You can view the report in the print preview window, close the window, use the scroll button on the mouse to change pages, etc. BUT, if you click on the preview itself, and attempt to scroll down to the bottom of the page, a 'lockup' appears to happen. I've just been waiting around hoping for it to be fixed. Today, for giggles, I decided to run the whole Visual Foxpro development environment. It ran! (BTW, I'm trying to do this all with fake windows, and all I've added is the VFP 5 runtime) BUT, anytime I click in an edit Window, MDI interface, the program acts as if I'm holding the shift key down, and as I move my mouse, all the text gets highlighted. I can't 'turn it off', so if there wasn't any text there, it surely would appear locked. I've changed the config from the fake_windows, to point to my Win2k install, but the behavior is the same. I'm actually getting kind of excited now, because we're a small company, and all we run is Fox5 apps (SBT / Skyline -- well, and a couple Fox2.6 win), and Office 2k. If I can run the development environment in Linux, I can take a real look at using linux desktops, either directly, or via LTSP. I don't get any debug info when the 'shift' occurs, and I'm not sure how to dump enough information to see the 'shift keypress' happen (assuming I could fix the problem myself in a way that doesn't interfere with the programming standards..), can someone point me in the right direction? Thanks for your time. Rick Romero

1 0

Proposed solution for mouse capture problems
by Jukka Heinonen 29 Nov '01

29 Nov '01

Okay, here is my proposal about how to fix broken message handling when mouse capturing is in effect. I would like to get some comments so that I can see that I haven't missed anything essential and because I would like to know whether someone is already working on this... Proposal has three parts, but part number one is the most important one, other two parts just show what would need to be done to make capturing work like described in MSDN documentation. 1. Function process_raw_mouse_message should only determine which window was under mouse and resend message to that window as a cooked message. Everything else (especially separating normal messages from nonclient messages and handling mouse captures) should be moved to process_cooked_mouse_message. Actually, I fail to see why raw messages are needed at all, since function SendInput could do this as well. 2. When requesting queued messages from wineserver, the request should also include the window that is capturing mouse input in the current thread - or this could be stored in the wineserver. If there are queued cooked mouse messages, wineserver considers them as if all child windows of capturing window had the handle of the capturing window. This should prevent problems if application requests messages about a single window. 3. Supporting multi-threaded capture is actually the easiest part, although it might be quite useless (Does any application really require it?). When mouse button is pressed in capturing window, process_cooked_mouse_message sets process-wide flag that states that global capture is in effect. After that, either process_raw_mouse_message or SendInput sees that this flag is set and resends all mouse messages to capturing window until button release message is received, which clears the flag. Function process_cooked_mouse_message needs to eat these messages if target window was not capturing window anymore. Proper locking should make sure that no important messages are lost (mouse move events are not important; we might lose button release event, but only if capture has been stopped manually before that and in that case not delivering button release is likely the best thing to do). -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: [patch] Winsock fixes
by Ove Kaaven 29 Nov '01

29 Nov '01

On Wed, 28 Nov 2001, Paul Rupe wrote: > I have found two bugs in dlls/winsock/socket.c. One I posted about a > few days ago in wine.devel. WS_accept calls WS_getpeername but passes > it the Unix file descriptor rather than the Windows socket handle. A > simple one-line change takes care of that. That's Francois's fault, when he split out the sockaddr_xxx conversions. > The second problem is more subtle, and I'm not sure if my solution is > enough. In WINSOCK_DoAsyncEvent there is a loop that dispatches all > events currently available on the socket. The problem is the order, it > simply calls them in increasing order by FD_xxx values. Since FD_READ > is numerically smaller than FD_CONNECT, a socket that has both events > will fire the read event before the connect. When that happens, the app > gets a read event before it thinks it's connected and ignores it. > Ideally, the loop should post them in the order in which they occurred, > but does wine keep track of that? Instead, I changed the loop so that > it checks FD_CONNECT and FD_CLOSE before FD_READ and FD_WRITE. I'm not > sure if the order I chose is the optimal one, but the app I was testing > (Xnews) works every time now. It'd seem to me that FD_CLOSE should be dispatched last, not first... Anyway, now that Alexandre moved the window message queues away from the wine clients and into the wineserver, these event message dispatches could also be done in the wineserver (where the winsock events are generated), instead of using the service thread callback WINSOCK_DoAsyncEvent. Alexandre wants to phase out the service thread anyway, so he probably won't oppose this. Any volunteers for that?

1 0

New Idea
by Matt Q 29 Nov '01

29 Nov '01

I don't know if this is the right news group for this but what the heck... This is a new idea I had. It strikes me that it would be better if wine some how customised it's self to a single users software/configuration... I'd heard that sometimes when one thing is fixed it sometimes breaks another... This wouldn't be a problem if the thing that would hypothetically get broken wasn't installed on the end users machine... so theoretically if you had some way of sending a patch to an end user which corrected the problem at hand it would be good... so what if every time wine crashed it popped up a window and if the user wished it it would send it's very verbose out put to some kind of a bug reporting system (repository)... and in return search the repository for a patch for this particular problem... (using the verbose output).... there is a chance that the patch might break something else but in that case there is a chance that it might find another patch to fix the whole situation... they have a system like this under M$ Win and netscape except that they rely on periodic updates to take care of the problem... but who is to say that every computer is built the Same and has the Same sofware so that the Same super patch will fix every one's computer... Note 1... If M$ screws anyone on rights to this idea they can claim next logical step kind of like one step shopping... Note 2... Basically the only two weakness of the system would be One the inablility to match the output with a patch... but with a decent database program should that be problem? and Two having enough programers to right mini patches..... I'm writing from memory but I think there are 300 developers.... wouldn't that be enough..... just a thought though so take it with a grain of salt... p.s. what brought this to mind back when I was following the wine project much more closely, 2-3 years ago, when it was almost the only way to run windows programs under linux, I'd heard that many of the problems could be fixed by just a tweak here or there and mabey a few lines of code changed... still don't know much C so I doubt I'll be much help as a developer if you want to get back with me over this : ) ICQ# 135184436 turtleislow

1 0

Re: x11ddraw fix
by Glenn Schrader 28 Nov '01

28 Nov '01

Ove Kaaven wrote: > On Mon, 12 Nov 2001, geschrader wrote: > > Your reasoning makes sense but with your patch I get the following error: > > > > X Error of failed request: XF86DGADirectNotActivated > > Major opcode of failed request: 138 (XFree86-DGA) > > Minor opcode of failed request: 26 (XDGACreateColormap) > > Serial number of failed request: 3691 > > Current serial number in output stream: 3951 > > > > I'm not sure how to interpret this. Documentation for DGA seems to be > > pretty non-existant. Is this complaining that the CreateColormap failed > > because DGA wasn't activated or that DGA wasn't activated because > > of the colormap failure? > It's probably the former. I'm guessing that you need to create the > colormap on the same display that XDGAOpenFrameBuffer and XDGASetMode was > done on (those are currently done on thread_display(), you'll probably > have to change them too, then?) The two attached patches seem to do the job. Thanks for the hints. --- Glenn Schrader ------------------------------------------------------------------------ Index: dga2.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/dga2.c,v retrieving revision 1.5 diff -u -r1.5 dga2.c --- dga2.c 2001/09/11 00:32:33 1.5 +++ dga2.c 2001/11/20 22:13:32 @@ -102,7 +102,7 @@ { LPDDRAWI_DIRECTDRAW_LCL ddlocal = data->lpDD->lpExclusiveOwner; DWORD vram; - Display *display = thread_display(); + Display *display = gdi_display; data->ddRVal = DD_OK; if (data->dwModeIndex) { @@ -174,7 +174,7 @@ static DWORD PASCAL X11DRV_XF86DGA2_CreatePalette(LPDDHAL_CREATEPALETTEDATA data) { - Display *display = thread_display(); + Display *display = gdi_display; data->lpDDPalette->u1.dwReserved1 = TSXDGACreateColormap(display, DefaultScreen(display), dga_dev, AllocAll); if (data->lpColorTable) X11DRV_DDHAL_SetPalEntries(data->lpDDPalette->u1.dwReserved1, 0, 256, @@ -185,7 +185,7 @@ static DWORD PASCAL X11DRV_XF86DGA2_Flip(LPDDHAL_FLIPDATA data) { - Display *display = thread_display(); + Display *display = gdi_display; if (data->lpSurfCurr == X11DRV_DD_Primary) { DWORD ofs = data->lpSurfCurr->lpGbl->fpVidMem - dga_mem.fpStart; TSXDGASetViewport(display, DefaultScreen(display), @@ -199,7 +199,7 @@ static DWORD PASCAL X11DRV_XF86DGA2_SetPalette(LPDDHAL_SETPALETTEDATA data) { - Display *display = thread_display(); + Display *display = gdi_display; if ((data->lpDDSurface == X11DRV_DD_Primary) && data->lpDDPalette && data->lpDDPalette->u1.dwReserved1) { TSXDGAInstallColormap(display, DefaultScreen(display), data->lpDDPalette->u1.dwReserved1); Index: x11ddraw.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11ddraw.c,v retrieving revision 1.12 diff -u -r1.12 x11ddraw.c --- x11ddraw.c 2001/08/27 19:04:18 1.12 +++ x11ddraw.c 2001/11/20 22:13:42 @@ -49,7 +49,7 @@ static LRESULT WINAPI GrabWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { - Display *display = thread_display(); + Display *display = gdi_display; if(message != X11DRV_DD_GrabMessage) return CallWindowProcA(X11DRV_DD_GrabOldProcedure, hWnd, message, wParam, lParam); @@ -81,7 +81,7 @@ if(grab) { Window window = X11DRV_get_whole_window(GetFocus()); if(window) - XSetInputFocus(thread_display(), window, RevertToParent, CurrentTime); + XSetInputFocus(gdi_display, window, RevertToParent, CurrentTime); } if(!X11DRV_DD_GrabMessage)

2 4

Re: PATCH: xterm support for wineconsole
by eric pouech 28 Nov '01

28 Nov '01

Marcus Meissner wrote: > > Hi, > > This patch adds a XTERM backend to wineconsole. > > Some problems: > - In full screen text applications (like IDA), the cursor shows sometimes > up in the wrong spot. > - Scrolling does not work yet (so winedbg doesn't really work). > - Uses config.h. I still have some questions... from a technical point of view, what didn't you use an ncurse (for example) lib to handle the TERM issues ? the old code you grabbed doesn't work correctly for all TERM configurations... rewriting everythind isn't the solution IMO from a more usage point of view, it seemed that TERM support for wineconsole was more intended for supporting an existing UNIX console (like when starting a command line tool and use the current TERM for interacting with it), which would mean in wineconsole case passing to wineconsole the handles of current TERM. furthermore, how to you plan to choose, when starting wineconsole, from the Win32 and the xterm backend ? in other words, I'm more in favor of : - Win32 backend for normal usage - reusing current UNIX console when run in TERM mode (and not xterm), and with the support of text mode lib (like ncurses) A+

2 2

(no subject)
by Ryan C. Stallings 28 Nov '01

28 Nov '01

Hello all, I am new to the wine scene and would like to try my hand at a little wine hacking. Are there any bugs out there that would be easy for a newbie to fix while letting me learn a bit about the inner workings of wine? I have read all the material about getting started developing, but I am just lacking a bit of direction on what to work on :) Thanks for your help, ryan

4 3

fix triggers crash
by Michael Stefaniuc 28 Nov '01

28 Nov '01

Hello! I found a bug in ImageList_Merge (the count of the images in the imagelist wasn't set) and the trivial fix Index: imagelist.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/imagelist.c,v retrieving revision 1.43 diff -u -r1.43 imagelist.c --- imagelist.c 2001/09/10 23:09:04 1.43 +++ imagelist.c 2001/11/26 22:37:31 @@ -1918,6 +1918,7 @@ DeleteDC (hdcSrcImage); DeleteDC (hdcDstImage); + himlDst->cCurImage = 1; } return himlDst; =================================================================== triggers with FreeSolitaire (got it from tucows.com) following error (with crash): X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 53 (X_CreatePixmap) Serial number of failed request: 19761 Current serial number in output stream: 19852 This happens with the cvs code from today and I'm pretty shure that it worked perfectly with the cvs code from two days before. And without the patch above the error dosn't get triggered. This seems strange because the error seems to occur in x11drv.StretchBlt and ImageList_Merge dosn't call StretchBlt. To reproduce the crash start FreeSolitaire with the patch above applied, select a solitaire game and start dragging a card around and wine will crash. With --debugmsg +relay it takes sometimes longer to trigger the bug, just release the card I try dragging an other card (i never needed to release the second card yet, wine crashed before). I've attached the last 1000 lines of relay output, hope that helps. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel