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

Re: Wine List Control compatibility

by Tony Lambregts

Peter Quax wrote: >Hello, > >>>Some things will break if you start trying to use a bunch of native >>>DLLs. And especially trying to use the native comctrl is likely to break >>>things. >>> >>>That said, I downloaded and tried out the program. To get it to run, I >>>used these native DLLs: >>> > >>>With that, the listview appears to be working for me just fine, assuming >>>you are talking about the one with the labels Oefening, Titel, and Item. >>>This is with current CVS. >>> >>I get about the same thing with the same problems (except I havent >>crashed) but I have some time.It would be much easier if there is an >>english version of this program.I don't have a soundcard.(maybe thats >>why I havnt crashed yet). I probably could get one. Does anyone want to >>recommend a cheep one that works well with linux? >> > >Both of you, thanks very much for your help. > >First of all I forgot to mention that the use of sound is not an issue (we >don't use that at our school), so that is not a problem whatsoever. > >I tried using the dll configuration as given and indeed it shows the list >control (just as it did before), but as I mentioned the image lists are >incorrect. To demonstrate this, I've taken a couple of screen shots to give >you an idea of what it should look like : > >http://alpha.luc.ac.be/~lucp1313/juniorwin.jpg : this is the windows version >that shows the correct icons in the list control (at the bottom) > >http://alpha.luc.ac.be/~lucp1313/juniorwine.jpg : this is the wine version >which demonstrates the incorrect behaviour of the icons > >You can clearly see that there is a difference. Now, when I doubleclick for >example 4-1 in the 'oefening' column to start this exercise, the window that >comes up doesn't show all of the text. A second anomaly is that from time to >time, the cursor will disappear. This is shown in the next 2 screenshots : > >http://alpha.luc.ac.be/~lucp1313/juniorwin2.jpg : this is the windows >version that shows the correct text > >http://alpha.luc.ac.be/~lucp1313/juniorwine2.jpg : this is the wine version >which demonstrate the lack of text in the upper left corner > >I hope this made my problems a bit more clear ? Also, I'm afraid that there >isn't an english version of this package available. I tried contacting the >authors but they don't seem to respond to any of my emails. > >Again, thanks for all your help > >Regards, >Peter Quax. > It looks like its not translating the color palet correctly. What color depth are you running at? My guess is that it is 16. If this is correct then try increasing it. It may be that the text is just not showing up because of this problem. I have CC:ed the Wine development list in order that the real wine gurus can have a look at this. How long do you have before you have to subject the little children to the "Windows Solution". Tony Lambregts

March 30, 2002

RE: Improving the regression testing infrastructure

by Francois Gouget

On 29 Mar 2002, Geoffrey Hausheer wrote: > > > True. So what we need is to add a function in the > > testing framework > > > so that tests can get argc/argv/envp. Seems like a > > reasonable approach. > > I was more thinking adding some wt_argc and wt_argv, with init in main > > so that we don't have to deal with the portability issues of > > the __argc, > > __ ARGC... > > Is there a reason we can't just use environment variables > rather than argc/argv? I would think that would be less > of a hassle than using argc/argv. The goal of some of these tests is precisely to check that what you get in argc/argv is what you expect. For instance, if the command line specified to CreateProcess is ... "a\"b\\" c\" d you would expect: argv[1] = [a"b\] argv[2] = [c"] argv[3] = [d] That would be hard to check without accessing argc/argv in some way. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

March 30, 2002

Re: Improving the regression testing infrastructure

by Francois Gouget

On Fri, 29 Mar 2002, Eric Pouech wrote: > > True. So what we need is to add a function in the testing framework > > so that tests can get argc/argv/envp. Seems like a reasonable approach. > I was more thinking adding some wt_argc and wt_argv, with init in main > so that we don't have to deal with the portability issues of the __argc, > __ ARGC... Yes I agree with the wt_argc, etc approach. Either variables or functions, or even a single function: int wt_getmainargs(char*** argv, char*** envp); These are all pretty much equivalent. > > > I decided to let the parent do the checking because: > > > - you don't know what the stdout of the child will be (and if you'll be > > > able to get the results on the console) > > > > It should have the same stdout as the parent, unless you explicitely > > nuke them when calling CreateProcess. > yup... but we want to test CreateProcess, and some test cases will > change the stdout handle But do you need to write to stdout for these tests. Do you need to write to stdout at all for that matter? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.

March 30, 2002

Re: Improving the regression testing infrastructure

by Eric Pouech

Geoffrey Hausheer a écrit : > > > > True. So what we need is to add a function in the > > testing framework > > > so that tests can get argc/argv/envp. Seems like a > > reasonable approach. > > I was more thinking adding some wt_argc and wt_argv, with init in main > > so that we don't have to deal with the portability issues of > > the __argc, > > __ ARGC... > > Is there a reason we can't just use environment variables > rather than argc/argv? I would think that would be less > of a hassle than using argc/argv. on the same address space across several threads, no need for env variables, all the threads share the same address space when between two processes, then the argc/argv is passed anyway (arguments to main) the only place where you could need then is for testing in child that you get the correct strings (see exchanges with François around this)

March 29, 2002

Re: Improving the regression testing infrastructure

by Eric Pouech

> True. So what we need is to add a function in the testing framework > so that tests can get argc/argv/envp. Seems like a reasonable approach. I was more thinking adding some wt_argc and wt_argv, with init in main so that we don't have to deal with the portability issues of the __argc, __ ARGC... > > I decided to let the parent do the checking because: > > - you don't know what the stdout of the child will be (and if you'll be > > able to get the results on the console) > > It should have the same stdout as the parent, unless you explicitely > nuke them when calling CreateProcess. yup... but we want to test CreateProcess, and some test cases will change the stdout handle > > - make process depends on result of the parent for success/failure > > Yes, the child should have an exit code that indicates success and > another one that indicates failure. The parent checks that and returns > success or failure as appropriate. either way

March 29, 2002

Re: Improving the regression testing infrastructure

by Francois Gouget

On Fri, 29 Mar 2002, Eric Pouech wrote: > Francois Gouget a écrit : > > > > On Fri, 29 Mar 2002, Eric Pouech wrote: > > For the parameter testing I was thinking of storing the expected argv > > parameters in environment variables. Then, we need a way to tell the > > child to do specific tests (maybe one more environment variable) and it > > would then compare the contents of the environment variables with what > > it got. > > > > But since we do not control the main/WinMain, we would have to rely > > on getmainargs or __argv, __argp tricks (which means parts of the test > > may only be possible in msvcrt). > I don't follow you... we got access to main (what is missing is just > letting the test procs access argc/argv pair True. So what we need is to add a function in the testing framework so that tests can get argc/argv/envp. Seems like a reasonable approach. > I decided to let the parent do the checking because: > - you don't know what the stdout of the child will be (and if you'll be > able to get the results on the console) It should have the same stdout as the parent, unless you explicitely nuke them when calling CreateProcess. > - make process depends on result of the parent for success/failure Yes, the child should have an exit code that indicates success and another one that indicates failure. The parent checks that and returns success or failure as appropriate. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

March 29, 2002

Unicode header control used by listview

by Uwe Bonnes

Hallo, some application made from a zip archive "4957.exe", that uses the listview.c sample from microsoft floating around since at least 1996, uses commctrl headers and shows only the first letter of the text in the header tabs. This is caused by (wine) listview.c creating the header windows as unicode, but in the commctrl initialization the header class was registered as ascii. When the header text is inserted, it is translated to unicode. When it is read out for display, it is treated as ascii, as the unicode flag of the header control isn't set. So reading of only one character succeeds. So either we set the header unicode-flag when creating the header control in listview, or we register the header class as unicode. Appended patch switches the charset after creating the control in listview.c. Does this sound right? Feedback welcome! Changelog dlls/comctrl32/listview.c: LISTVIEW_Create Switch header control charset to unicode -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing -- Index: wine/dlls/comctl32/listview.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/listview.c,v retrieving revision 1.125 diff -u -r1.125 listview.c --- wine/dlls/comctl32/listview.c 20 Mar 2002 00:53:42 -0000 1.125 +++ wine/dlls/comctl32/listview.c 29 Mar 2002 20:58:21 -0000 @@ -8002,6 +8002,9 @@ 0, 0, 0, 0, hwnd, (HMENU)0, lpcs->hInstance, NULL); + /* set header unicode format */ + SendMessageW(infoPtr->hwndHeader, HDM_SETUNICODEFORMAT,(WPARAM)TRUE,(LPARAM)NULL); + /* set header font */ SendMessageW(infoPtr->hwndHeader, WM_SETFONT, (WPARAM)infoPtr->hFont, (LPARAM)TRUE);

March 29, 2002

Re: Improving the regression testing infrastructure

by Eric Pouech

Francois Gouget a écrit : > > On Fri, 29 Mar 2002, Eric Pouech wrote: > For the parameter testing I was thinking of storing the expected argv > parameters in environment variables. Then, we need a way to tell the > child to do specific tests (maybe one more environment variable) and it > would then compare the contents of the environment variables with what > it got. > > But since we do not control the main/WinMain, we would have to rely > on getmainargs or __argv, __argp tricks (which means parts of the test > may only be possible in msvcrt). I don't follow you... we got access to main (what is missing is just letting the test procs access argc/argv pair > The approach above would probably not work testing environment > variable passing. So alternately, since the two share the same code, you > could instruct the child to expect to receive the data corresponding to > global array 5. anyway, since the test program is a CUI, the proposed scheme doesn't test either the WinMain part only the argc/argv part of main (the rest of the parsing is either in msvcrt or shell32 (for the unicode part)) I decided to let the parent do the checking because: - you don't know what the stdout of the child will be (and if you'll be able to get the results on the console) - make process depends on result of the parent for success/failure anyway, any test would be compare data (or behavior) from parent and child which means that you need a way to pass data from one to the other for the reason explained above, I think it's better to let the parent do the final testing. anyway, it may show that the child being only the same process as the parent with different arguments fails for: - CUI and GUI testing - independance of crt0 as I said, I choose the temp file because it's independent of any of the other bits (I mainly use the unix C lib) other ways would include: - env variables (but you may have limitations on the length of the var...) - registry (that would be, in term of coding, much more cleaner, but would require handle inheritance for testing the process creation...) - shared mem... so, a mechanism used by two processes. so I'd rather test the process creation first, and then the IPC mechanisms A+

March 29, 2002

freetype

by Morten Welinder

I get the message *** Note: Your system appears to have the FreeType 2 runtime libraries *** installed, but 'freetype-config' is not in your PATH. Install the *** freetype-devel package (or its equivalent on your distribution) to *** enable Wine to use TrueType fonts. even though I do have freetype-config in my PATH. It seems related to the test dnl Check that we have at least freetype/freetype.h if test "$ac_cv_header_freetype_freetype_h" = "yes" -a "$wine_cv_fttrigon" = "yes" (Note: comments, message, and code do not agree) I don't seem to have the <ft2build.h> and <freetype/fttrigon.h> files. Should I? This is on a SuSE7.3 system, FWIW. Morten

March 29, 2002

Re: Improving the regression testing infrastructure

by Francois Gouget

On Fri, 29 Mar 2002, Eric Pouech wrote: [...] > the global test goes as : > 1/ the parent creates the child > 2/ the parent waits for the child to terminate > 3/ the child process stores most information it can gather in a > temporary file > 4/ the child terminates > 5/ the parent does the final checking For the parameter testing I was thinking of storing the expected argv parameters in environment variables. Then, we need a way to tell the child to do specific tests (maybe one more environment variable) and it would then compare the contents of the environment variables with what it got. But since we do not control the main/WinMain, we would have to rely on getmainargs or __argv, __argp tricks (which means parts of the test may only be possible in msvcrt). The approach above would probably not work testing environment variable passing. So alternately, since the two share the same code, you could instruct the child to expect to receive the data corresponding to global array 5. Could one of the approaches above replace the temporary file approach? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

March 29, 2002