Re: comctl32/tests: Added first TaskDialog test.
On 06/13/11 06:54, André Hentschel wrote: IIRC the reason for the temporary file is that we can easily turn the v6 features on and off and AFAIK we can't if we have it hardcoded in a resource. I did not mean to hardcode as a resource of type RT_MANIFEST id 1, but rather some random id, then we can still manually load v6 using CreateActCtx, only we don't have to create a temporary file. On this page: http://msdn.microsoft.com/en-us/library/aa374149%28v=vs.85%29.aspx I point to you the members lpResourceName and hModule. That is what I was talking about. Sorry for the misunderstanding! - Patrick
Re: About building test suite for Windows
On 06/12/11 07:03, André Hentschel wrote: Hi, i had a look in my config.log and found in my 32-bit tree: ... configure:7022: checking for i686-mingw32msvc-gcc configure:7052: result: no configure:7022: checking for i586-mingw32msvc-gcc configure:7038: found /usr/bin/i586-mingw32msvc-gcc configure:7049: result: i586-mingw32msvc-gcc configure:7065: checking whether i586-mingw32msvc-gcc works configure:7078: i586-mingw32msvc-gcc -c -g -O2 conftest.c 5 configure:7078: $? = 0 configure:7079: result: yes ... so i had a look at configure and if i understand it correct it simply searches for one of these in your $PATH: i686-w64-mingw32-gcc i586-w64-mingw32-gcc i486-w64-mingw32-gcc i386-w64-mingw32-gcc i686-pc-mingw32-gcc i586-pc-mingw32-gcc i486-pc-mingw32-gcc i386-pc-mingw32-gcc i686-mingw32msvc-gcc i586-mingw32msvc-gcc i486-mingw32msvc-gcc i386-mingw32msvc-gcc i686-mingw32-gcc i586-mingw32-gcc i486-mingw32-gcc i386-mingw32-gcc so to state Maartens question more precisely: where is your mingw32-gcc binary, what's its name and is its path in your $PATH? My mingw32-gcc is in /usr/local/bin, its name is simply mingw32-gcc (no CPU name in there) and yes it's in $PATH. On 06/12/11 07:10, Nicolas Le Cam wrote: If I read the port's makefile right, using ./configure CROSSCC=mingw32-gcc should help. I tried this actually, and indeed the makefile stopped complaining, then winebuild started doing this instead: winebuild: Invalid target specification 'mingw32' A quick look in tools/winebuild/main.c (function set_target, line 194) shows that it chokes if the target specification does not contain at least one dash. Now I am wondering if it's my system which is at fault for being badly configured or if I should just modify winebuild so that it is more lenient in its parsing of the target? Thanks, - Patrick
Re: comctl32/tests: Added first TaskDialog test.
Hey, Patrick. Look at tests/listview.c for example to see how I load version 6 with activation context API. It doesn't work for some reason for XP SP3 (a glitch I don't understand), but works fine for everything else. All you need is v6util.h. Without version 6 activation this test is useless to run in auto mode, it will never find TaskDialog entry points. Thanks for your interest. Thanks for the information. I have redone my patch using it. I looked at v6util.h and could not help but notice two things though: - There is no need to set processorArchitecture to x86 or amd64 as far as I know, Windows will happily take * to mean whatever the currently applicable architecture is. - As a result of the previous comment, there would be no point to generate the manifest as a file, as it could be loaded from a resource (CreateActCtx supports this), that would seem cleaner to me than generating temporary files. - Patrick
About building test suite for Windows
Hi, As I was writing my task dialog test I ran into a few problems trying to test on Windows... First, I tried building it using make crosstest but I keep getting this: $ gmake crosstest crosstest is not supported (mingw not installed?) gmake: *** [crosstest] Error 1 I am on FreeBSD 8.2-RELEASE (i386), I have the following mingw ports installed (using pkg_add) mingw32-bin-msvcrt-r3.18.a3.14 mingw32-binutils-2.21,1 mingw32-directx-20020518 mingw32-gcc-4.5.0_1,1 mingw32-pdcurses-3.4 mingw32-pthreads-2.8.0 I deleted config.status (there was no config.cache) and re-ran ./configure, it fails to detect mingw, so I gave up on that. I then tried building them on Windows directly instead (using Visual Studio 2008 with Windows SDK v7.0) as describred there: http://www.winehq.org/docs/winedev-guide/testing-windows However, trying to compile comctl32_tests using the WINE headers would complain about EXCEPTION_EXECUTE_HANDLER being undefined. On the other hand, compiling with the MSVC headers would complain about TVIS_FOCUSED not being present. According to this: http://support.microsoft.com/kb/166471 it has been deprecated and removed from MS headers a long time ago. Eventually I would like to just be able to make crosstest so that I can stay in one dev environments and not two, so if anybody could help me about why isn't mingw32 detected, I would like it. Thanks. - Patrick
Re: TaskDialog implementation
(Sorry for the late reply. BSD dev machine had some hard disk issues.) Thanks for all your input. Here are some comments: On 06/09/11 10:51, Juan Lang wrote: The patch was marked as Pending. That usually means Alexandre's waiting for something, e.g. for you to fix something obvious, or to see what else you're planning to do. Since you say the patch is preparatory work, it doesn't make much sense to go in unless the remaining patches are also to go in, so I'd suggest sending at least another patch to show where you're going with it. Alright, I will follow-up with more first then. Regarding splitting, sometimes it's useful to introduce code that will only be removed later. I know this isn't the usual advice, but if you introduce a new implementation of something, sometimes a stub implementation can appear first. E.g., if it's an interface you're implementing, introduce an implementation that does nothing but return E_NOTIMPL from each method. Then one by one introduce implementation for each function. Thing is, however, that I already got the full implementation written as a block, short of replaying my coding process, I don't see how I could efficiently do that. I could always make different patches for different parts, like, dialog creation, then layout, then message handling, etc, but you would not get a working TaskDialog until the last patch was integrated. On 06/09/11 10:55, Vincent Povirk wrote: +if (pnButton) *pnButton = IDYES; +if (pnRadioButton) *pnRadioButton = pTaskConfig-nDefaultButton; +if (pfVerificationFlagChecked) *pfVerificationFlagChecked = TRUE; +return S_OK; I don't think it's appropriate to make selections for the user like this. If you can't present all of the choices to the user, you should probably return E_NOTIMPL. Yes, I agree, if I had made that stub myself I would have returned E_NOTIMPL, but I merely moved it as-is from commctrl.c, I assume it was put there that way quickly to make some application work, I did not want to break anything. I think Lats' advice here is sound. You might start with a dialog with only an OK button (that only displays if the dialog offers no choices to the user), then add features one at a time. Well, you shouldn't write it all at once anyway, as you'd likely have to change all of your later work. Thing is, as I mentioned earlier, the code is already all written and working. (You can download the DLL from my website and see for yourself) On 06/09/11 11:15, Dan Kegel wrote: An iota of guidance was provided at http://source.winehq.org/patches/ Scroll down to your patch, you can see it's in Pending state. Scroll down further, you'll see that Pending means The patch is not obviously correct at first glance. Making a more convincing argument, preferably in the form of a test case, may help. See also http://wiki.winehq.org/SubmittingPatches for a generic checklist. Thanks for those two sites, I did not know / forgot they existed. They have been bookmarked so I will check them first before asking. Your patch seemed to do three things: - moving old stub into new file - adding a TaskDialog function - adding ordinals Those three things could all be separate patches, and some of them could have tests. I would like some guidance on what constitutes an adequate patch size then. According to this, I shoud make a commit into my local git every time I do something simple. I can (and will) split this patch as you mention, but I fail to see how I could split my patches as I get into the meat of my implementation (as I mentioned earlier). Input in this area would be appreciated. Also how do I write a test that tests the ordinals? By checking that GetProcAddress(hMod, TaskDialogIndirect) == GetProcAddress(hMod, #345) ? I'd suggest sending just one of the three first (probably not the one that moves code to a new file), and including a test with the first patch. - Dan Alright, will do. What I seem to get from your input and reading SubmittingPatches, is basically tests, tests, tests. I thought a while about how does one automate tests on GUI stuff? and how can I ensure that my dialog renders right in a test, short of using a flaky thing like GetPixel()?, etc. Then it came to me. What I will do is first change the implementation to return E_NOTIMPL as Vincent Povirk suggested. Then I will start writing tests that show use TaskDialogIndirect and sends a bunch of TDM_xxx messages and tests that the callback procedures receives all the right TDN_xxx notifications, at least. It won't be able to test that the dialog _displays_ right, but at least that it functions right from an API point of view. As long as I can close the dialog when done testing, the tests should not require any kind of user interaction. Of course any input is appreciated, I am still a newbie at this. - Patrick
TaskDialog implementation
Hello everyone, I'd like to port my re-implementation of task dialogs (http://www.korosoft.net/projects/tdemu/) to WINE, actually I have posted a small patch yesterday (merely rearranges some source around, preparatory work) which sadly did not seem to get accepted. I'm going to take my code and clean it to WINE's source code standards, however I do not see how I could split it in many patches as everything is dependant on everything else. As this is quite a big amount of work, I would like to have some guidance (what must I do to be sure it is accepted) so that I do not end up doing all that for nothing - starting by knowing why my patch from yesterday was not accepted (what did I do wrong). Thanks for your time and help.
