February 2017 - Wine-Devel - list.winehq.org

Re: [06/18] comctl32: TaskDialog - Implement main and content text controls

by Fabian Maurer

> That's what I suspected :) In my (irrelevant) opinion, it would be fine to > leave the text empty in this special case for now, but it should not crash. > You could do e.g. "if (!IS_INTRESOURCE(...) && !STR_EMPTY(...))". Good idea, I'll do it like that. Regards, Fabian Maurer

Feb. 24, 2017

Re: [06/18] comctl32: TaskDialog - Implement main and content text controls

by Joachim Priesner

Am Friday, 24. February 2017 schrieb Fabian Maurer: > > Right now passing something that is not a string crashes the dialog, which > > probably should not happen. To get the string if a resource ID has been > > passed you can use something like > Thanks, probably should have added this already, or at least note it. > It was on my todo for a while, then I decided to first get the dialog working > properly. That's what I suspected :) In my (irrelevant) opinion, it would be fine to leave the text empty in this special case for now, but it should not crash. You could do e.g. "if (!IS_INTRESOURCE(...) && !STR_EMPTY(...))".

Feb. 24, 2017

Re: [06/18] comctl32: TaskDialog - Implement main and content text controls

by Fabian Maurer

> Right now passing something that is not a string crashes the dialog, which > probably should not happen. To get the string if a resource ID has been > passed you can use something like Thanks, probably should have added this already, or at least note it. It was on my todo for a while, then I decided to first get the dialog working properly. I wanted to get a simple implementation in first, I'm still missing a lot of important features, but it should be a good enough replacement for the solution we currently have. Should I add this feature into this patchset, or is it ok if I add it once I got this upstream? Regards, Fabian Maurer

Feb. 24, 2017

Re: wineinstall - Add support for parallel builds using 'nproc' to detect cpu count

by Francois Gouget

On Fri, 24 Feb 2017, Austin English wrote: [...] > >>> Actually we use backticks everywhere because that was necessary for > >>> Solaris. > > > >> Seriously? Is that still the case / what version of Solaris was that, > >> if you remember? > > > > Solaris seems to never upgrade the core utilities, so any version I'd > > guess. But I haven't touched Solaris in a while (fortunately ;-) > > Francois, do you know if this still an issue? I don't run Solaris much either. Still have my Solaris 11.11 VM though. I ran the following script on it: $ cat >foo <<EOF b=`which nproc` echo "b=[$b]" p=$(which nproc) echo "p=[$p]" EOF $ /bin/sh foo b=[/usr/bin/nproc] p=[/usr/bin/nproc] $ /bin/sh --version | head -n 1 GNU bash, version 4.1.9(1)-release (i386-pc-solaris2.11) $ /bin/ksh foo b=[/usr/bin/nproc] p=[/usr/bin/nproc] $ /bin/ksh --version version sh (AT&T Research) 93u 2011-02-08 So it seems to work. That said if the rest of the code does it one way and the new way does not bring a significant improvement I see no reason to stray from existing practices. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

Feb. 24, 2017

Re: [18/18] comctl32: TaskDialog - Add ability to cancel dialog

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=28889 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:631: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:631: Test failed: TaskDialogIndirect not exported by name. === w7pro64 (64 bit taskdialog) === 0718:taskdialog: unhandled exception c0000005 at 000000000046211E === w1064 (64 bit taskdialog) === 0b44:taskdialog: unhandled exception c0000005 at 000000000046211E

Feb. 24, 2017

Re: [09/18] comctl32: TaskDialog - make thread-safe

by Fabian Maurer

> Why do you need such a list? The DialogProc needs to access some additional information, like whether the dialog be cancelled or not, or the callback pointer. If you have a better idea to solve this problem, I'd love to hear it. That was just the one I came up with. Regards, Fabian Maurer

Feb. 24, 2017

Re: [06/18] comctl32: TaskDialog - Implement main and content text controls

by Joachim Priesner

Glad to see that someone is finally implementing this properly :) > @@ -276,7 +324,33 @@ HRESULT WINAPI TaskDialogIndirect(const TASKDIALOGCONFIG *pTaskConfig, int *pnBu > > /* Start creating controls */ > > - controls_add(controls, IDOK, class_button, text_ok, WS_CHILD | WS_VISIBLE, 105, 85, 40, 10); > + if(!STR_EMPTY(pTaskConfig->pszMainInstruction)) > + { > + RECT rect; > + > + SelectObject(dc_dummy, font_main); > + rect = text_get_rect(dc_dummy, pTaskConfig->pszMainInstruction, dialog_width); > + > + controls_add(controls, ID_TEXTMAIN, class_static, pTaskConfig->pszMainInstruction, > + WS_CHILD | WS_VISIBLE, 5, dialog_height + 5, rect.right, rect.bottom); The psz* parameters (e.g. pszMainInstruction) can contain a resource ID instead of a string. (Passing an invalid ID just results in an empty string.) Right now passing something that is not a string crashes the dialog, which probably should not happen. To get the string if a resource ID has been passed you can use something like +/* Fills "result" with a pointer to the string specified by "text", which may be a resource identifier. */ +static HRESULT TASKDIALOG_GetText(const WCHAR *text, HINSTANCE instance, const WCHAR **result) +{ + if (IS_INTRESOURCE(text)) + { + SetLastError(S_OK); + LoadStringW(instance, LOWORD(text), (LPWSTR)result, 0); + return HRESULT_FROM_WIN32(GetLastError()); + } + else + { + *result = text; + return S_OK; + } +}

Feb. 24, 2017

Re: [09/18] comctl32: TaskDialog - make thread-safe

by Nikolay Sivov

On 25.02.2017 0:43, Fabian Maurer wrote: >> Why would you need something like that? What is unsafe about regular >> dialog window? > Since there can be multiple taskdialogs open at the same time, I figured the > instance-list should only be accessed in a thread-safe manner. Am I wrong > there? Why do you need such a list? > > Regards, > Fabian Maurer >

Feb. 24, 2017

Re: [17/18] comctl32: TaskDialog - Implement TDM_HELP and add tests

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=28888 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:550: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:550: Test failed: TaskDialogIndirect not exported by name. === w7pro64 (64 bit taskdialog) === 06fc:taskdialog: unhandled exception c0000005 at 000000000046211E === w1064 (64 bit taskdialog) === 0e6c:taskdialog: unhandled exception c0000005 at 000000000046211E

Feb. 24, 2017

Re: [16/18] comctl32: Taskdialog - Implement TDM_ENABLE_BUTTON and add tests

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=28887 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:531: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:531: Test failed: TaskDialogIndirect not exported by name. === w7pro64 (64 bit taskdialog) === 0438:taskdialog: unhandled exception c0000005 at 000000000046211E === w864 (64 bit taskdialog) === 0f54:taskdialog: unhandled exception c0000005 at 000000000046211E === w1064 (64 bit taskdialog) === 0e44:taskdialog: unhandled exception c0000005 at 000000000046211E

Feb. 24, 2017