- Wine-Devel - list.winehq.org

Re: taskmodal messagebox implementation, take 3
by Ivan Leo Puoti Nov. 14, 2004

Nov. 14, 2004

> No problem. I'll give a lengthy reply in the hope it can help other folks > dealing with this sort of thing too. Well, your code works, and I've made it into a patch. I've also removed what I beleive is a useless if check from MSGBOX_OnInit(). Due to my lame webmail client you code arrived with no indentation, so in the future please attach any code you send to me. If you think the attached patch is OK I'll forward it to wine-patches. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

2 1

Re: [D3D] Some surfaces related fixes
by Christian Costa Nov. 14, 2004

Nov. 14, 2004

Mike Hearn wrote: >On Sun, 14 Nov 2004 13:40:15 +0000, Christian Costa wrote: > > >>+ if ((pDDSD->dwFlags & DDSD_LPSURFACE) && (pDDSD->lpSurface == NULL)) { >>+ /* Frank Herbert's Dune specifies a null pointer for the surface, ignore the LPSURFACE field */ >>+ FIXME("Null surface pointer specified, ignore it!\n"); >>+ pDDSD->dwFlags &= ~DDSD_LPSURFACE; >>+ } >>+ >> >> > >Apps passing in bogus data should normally be a trace or warn at most, >unles there is actually something to fix here it doesn't make sense to use >a fixme as it'll inevitably get users asking about it .... > >thanks -mike > > > > > Your're right, Mike. :-) I will resend a patch for that. Thanks. Christian

1 0

Re: taskmodal messagebox implementation, take 3
by Juan Lang Nov. 14, 2004

Nov. 14, 2004

Hi Ivan. --- Ivan Leo Puoti <puoti(a)inwind.it> wrote: > Please consider I'm no programming wiz and I'm learning as I go along. No problem. I'll give a lengthy reply in the hope it can help other folks dealing with this sort of thing too. > Now, I don't see how else I could get MSGBOX_EnumProc() to remember the > values > of those that now are static variables, apart from using the heap for > everything, that seems a bit inefficent as we know how much data we want > to > store, or global variables, do you think I should use global ones > instead? > If not suggestions are welcome. Globals are also not thread-safe. Generally for thread safety, I'd suggest the following: declare a structure that has all the data you want to modify in MSGBOX_EnumProc, something like: struct MsgBoxEnumProcParams { int pass; int counter1; int counter2; int heapcheck; HWND *handles; }; In MessageBoxIndirectW, create one of these and pass its address as the LPARAM value to EnumThreadWindows(). However, this ignores style issues. I have problems with names like "counter1" and "counter2"; they don't tell me what they mean. Also, I don't like the magic values 0, 1, 2, 3, 4 for the LPARAM value; at the least these should be symbolic constants. Pass 3 doesn't modify the parameters at all, so it really should get its own callback function. It looks like heapcheck's purpose is to see whether handles has in fact been allocated. You could instead make sure to set handles to NULL when it isn't allocated. Also, there's the possibility of a memory leak in pass 4. I'd suggest the caller should be responsible for memory allocation. With these suggestions, I've come up with the following changes. I haven't checked whether this code works (or even compiles), it's just my attempt at rewriting what you're trying to do: struct ThreadWindows { UINT numHandles; UINT handlesLen; HWND *handles; }; BOOL CALLBACK MSGBOX_CountDisabledThreadWindows(HWND hwnd, LPARAM lParam) { if (!lParam) return FALSE; if (!IsWindowEnabled(hwnd)) *(UINT *)lParam++; return TRUE; } BOOL CALLBACK MSGBOX_EnumDisabledThreadWindows(HWND hwnd, LPARAM lParam) { if (!lParam) return FALSE; if (!IsWindowEnabled(hwnd)) { struct ThreadWindows *threadWindows = (struct ThreadWindows *)lParam; if (threadWindows->numHandles < threadWindows->handlesLen) threadWindows->handles[threadWindows->numHandles++] = hwnd; } return TRUE; } INT WINAPI MessageBoxIndirectW( LPMSGBOXPARAMSW msgbox ) { LPVOID tmplate; HRSRC hRes; int ret; UINT i; struct ThreadWindows threadWindows = { 0, 0, 0 }; static const WCHAR msg_box_res_nameW[] = { 'M','S','G','B','O','X',0 }; if (!(hRes = FindResourceExW(user32_module, (LPWSTR)RT_DIALOG, msg_box_res_nameW, msgbox->dwLanguageId))) return 0; if (!(tmplate = (LPVOID)LoadResource(user32_module, hRes))) return 0; /*handle task modal message boxes*/ if ((msgbox->dwStyle & MB_TASKMODAL) && (msgbox->hwndOwner==NULL)) { EnumThreadWindows(GetCurrentThreadId(), MSGBOX_CountDisabledThreadWindows, (LPARAM)&threadWindows.numHandles); if (threadWindows.numHandles) { threadWindows.handles = (HWND *)HeapAlloc(GetProcessHeap(), 0, threadWindows.numHandles * sizeof(HWND)); if (threadWindows.handles) threadWindows.handlesLen = threadWindows.numHandles; threadWindows.numHandles = 0; } EnumThreadWindows(GetCurrentThreadId(), MSGBOX_EnumDisabledThreadWindows, (LPARAM)&threadWindows); for (i = 0; i < threadWindows.numHandles; i++) DIALOG_DisableOwner(threadWindows.handles[i]); } ret=DialogBoxIndirectParamW(msgbox->hInstance, tmplate, msgbox->hwndOwner, MSGBOX_DlgProc, (LPARAM)msgbox); if ((msgbox->dwStyle & MB_TASKMODAL) && (msgbox->hwndOwner==NULL)) { for (i = 0; i < threadWindows.numHandles; i++) DIALOG_EnableOwner(threadWindows.handles[i]); if (threadWindows.handles) HeapFree(GetProcessHeap(), 0, threadWindows.handles); } return ret; } The changes I've made: I've renamed counter1 and counter2 to numHandles and handlesLen. handlesLen is the allocated number of handles, while numHandles is the number of handles actually stored. (Your code already dealt with the possibility of their being different: well done!) I've also used handles as its own guard; if it's NULL, it's not allocated. Otherwise it is. Like I suggested, I pass a pointer as an LPARAM to the two EnumThreadWindows callback functions. It seems two calls to EnumThreadWindows were unnecessary, since we already knew the window handles, so I just iterate over the values in handles rather than calling EnumThreadWindows again. If I'm incorrect in my understanding, of course change it. And, the caller is always responsible for memory allocation and freeing. I think this is safer than having the callback function do it. > >Any reason you aren't using HeapAlloc instead? > As this heap is only used by MSGBOX_EnumProc(), is there any reason why > I should > use HeapAlloc? It's sometimes easier to debug memory problems with the Windows heaps than with the libc ones. --Juan __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

1 0

winzip 9 doesn't run under wine :-(
by Dan Kegel Nov. 14, 2004

Nov. 14, 2004

While putting together a tutorial on how to contribute test cases to Wine (http://kegel.com/wine/sweng/) I noticed that the current version 9 of WinZip doesn't install under vanilla Wine; it aborts with the message WinZip was unable to locate a recent version of the Windows HTML help viewer, which is required to display WinZip help. ... Seems like a bit of a showstopper. What's the plan for addressing this? Is it a 0.9 feature? - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

3 8

ListView DrawText Flags
by Zach Gorman Nov. 14, 2004

Nov. 14, 2004

Dimitrie - You have a patch back in 2002 that cleans up the listview DrawText() code in comctl32. When calling DrawText from a single-line edit control, you don't pass DT_NOPREFIX. Is this intentional, or just an oversight? My testing on Windows shows that & characters do not get converted to _ even in the single-line edit control case (indicating that DT_NOPREFIX should be passed). Thanks, Zach

2 1

Missing file names in WINEDBG
by lats Nov. 14, 2004

Nov. 14, 2004

In the last week WINEDBG has stopped outputting the file/path and linenumber of entries in the backtrace. Does anyone know what happened? Jeff

3 3

Re: taskmodal messagebox implementation, take 3
by Juan Lang Nov. 14, 2004

Nov. 14, 2004

Ivan, a couple comments on this. You wrote: +BOOL CALLBACK MSGBOX_EnumProc(HWND hwnd, LPARAM lParam) +{ + static int counter1, counter2, heapcheck=0; + static HWND *handles; static variables aren't thread safe. Two threads attempting to do task modal dialogs (yes, this is probably strange) could result in weird failures. + handles=(HWND*)malloc(counter1*sizeof(HWND)); Any reason you aren't using HeapAlloc instead? --Juan __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

1 0

dlls/commdlg/fontdlg.c regression
by Gerald Pfeifer Nov. 13, 2004

Nov. 13, 2004

The following change to dlls/commdlg/fontdlg.c revision 1.70 date: 2004/08/14 00:42:35; author: julliard; state: Exp; lines: +2 -5 Jacek Caban <jack(a)itma.pwr.wroc.pl> Fix a bug in passing parameters to CFn_WMInitDialog and CFn_WMCommand in FormatCharDlgProcW. causes the following warning with GCC 3.3.2 on FreeBSD 4.10: fontdlg.c:1161: warning: passing arg 4 of `CFn_WMCommand' from incompatible pointer type Would you mind fixing this? Thanks, Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

2 3

Using a DIB to reduce number of calls to X
by Arjen Nienhuis Nov. 13, 2004

Nov. 13, 2004

GradientFill can be implemented by drawing to a DIB, and then blting that DIB to the screen. This will reduce the number of calls to X from O(n) to O(1). 1. Is that a good idea? Any caveats? 2. Can that method be used elsewhere? I'll try to implement it right away. P.S. We do implement the alpha part of GradientFill the same as Windows. The comments might sugest otherwise.

2 1

For the appdb hackers
by Ivan Leo Puoti Nov. 13, 2004

Nov. 13, 2004

It would be great if I could delete/approve apps and go to the next one without having to go back to adminAppQueue.php Thanks for the work you're doing, it was badly needed. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

3 3