September 2003 - Wine-Devel

text edit box not painting text ( on form startup )
by Doug Herbert March 9, 2005

March 9, 2005

( I have posted a similiar question in wine-users, don't flame me for doing so, just thinking about this some more, perhaps it may be more a developer question ) Ok, I have a windows app, that runs under wine fine - not quite. This app has a form, with many text field edit boxes on. Quite often these edit boxes already have text values, ie. they are not empty - there is a database behind the form. Anyway, the form shows on the screen, but the text within the edit fields is invisible, until you activate each edit box component. When you leave one edit box to the next, the text remains visible. It seems like the repainting is not working, on initial startup of the form. As a way to debug this database app ( I don't have the source code for it ) I wrote a real basic form app in Visual Studio, with two edit boxes, with data in each. Now this basic app shows the text values immediately on startup. So there must be something different that the database app is not doing. I then ran wine using 'wine --debugmsg +edit programname' for both app's. I see both logging 'Creating ANSI edit control, style = xxxxx' but the style reference is different between apps - I am not sure if this the cause or not. The problem app reports style = 54011104 and the basic app shows style = 50010080. Can somebody explain what this style reference means and how do I force an app to use a certain style of edit box ? What other wine class debugmsg types should I use to narrow down the source of this problem ? Is there anyway I can check to see how the database app is repainting text within the text edit components ? Regards Doug Herbert. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 4

Wine history draft
by Brian Vincent (C) Jan. 27, 2004

Jan. 27, 2004

I put together the following: http://users.theshell.com/~vinn/wine-history.html There's two major additions I'd like to see and I don't think I'm capable of doing them: 1) Wine history from 1994 - 1999 with a specific emphasis on changes to the architecture, design decisions that got discarded, developers who've come and gone. 2) Specific quotes from over the years. I sort of put some examples of that in the document above. Humorous quotes would be especially nice. If no one has any suggestions then I'll likely just remove the existing ones and add the information to the relevant paragraphs. I'm also thinking of adding a paragraph on the tools and programs developed for Wine. Comments / suggestions / criticisms? --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

4 3

Configuration parameters
by Dimitrie O. Paun Nov. 22, 2003

Nov. 22, 2003

Hi folks, I've finally managed to do the table I've promised for so long. My appologies for the delay. This has been mind numbing work, and as such I haven't payed that much attention to the values I've filled in those columns. Please send me your comments so I can post a final version of this to the WineHQ site soon. Note: best viewed in a web browser, but an editor that can display about 150 columns would do just fine as well. -- Dimi.

7 20

Wine lecture slides
by Shachar Shemesh Nov. 4, 2003

Nov. 4, 2003

Hi all, I have placed on my site the slides for a presentation I gave at a local LUG about Wine. The slides are in English, in PDF format. You can get them at http://shemesh.biz/lectures.html The lecture was given several months ago, but I'm going to repeat it in about a month. If you have any comments, please send them over for inclusion for next time. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

9 16

Window refresh problem with GroupBox and Tabs
by George Marshall Oct. 21, 2003

Oct. 21, 2003

Hi I've already submitted this bug to the wine bugzilla but I'm posting it here as well 'cause... oh well you know. Pls. look at the end of the message for .gifs Bug 1689 follows: I've got an application which purpose is to just reproduce the wine bug I'm gonna explain below. There is, basically, a window, a tab control with four tabs, some GroupBoxes and a few editboxes. (Please, see the attached .gif to get an idea). Here we go with the interesting part... If you run the application you'll realize that some editboxes are not drawn at all and some other not correctly drawn (Expecially if you go through the tabs...) Now if you minimize and then raise this window or drag part of it out of the screen and then back in, everything in it is correctly "painted". The pic tabwin_ok.gif shows the application correctly drawn, while in tabwin_bad.gif you'll see the application in its bad behavior (Like described above). Another interesting thing to note is that if you go through the tabs backward( from the last one to the first one ) the window contents is correctly drawn, not if you go from the first tab to the last one. This is always reproducible. This bug is 100% reproducible with Wine 20030813, 20030709, 20030618 (the versions I could work with...) I'm actually trying to fix this by myself (an ugly workaround will do the job as well) but any help to get me to the right direction will be appriciated. You're more than welcome to ask for any debug or strace log. Thanks. http://bugs.winehq.org/attachment.cgi?id=359&action=view http://bugs.winehq.org/attachment.cgi?id=360&action=view

2 2

uxtheme.dll
by Kevin Oct. 3, 2003

Oct. 3, 2003

I started work porting a windows app using winelib, and hit an issue relating to the fact that there is currently no implementation of uxtheme.dll (and more importantly, no headers, of which would be enough to compile the app as it dynamically loads all the uxtheme dlls as needed, and falls back gracefully) Because of this, I've been thinking about beginning an implementation of uxtheme.dll. I am curious if someone has already taken up this task, or if anyone any opinions on this topic. Thanks Kevin

13 16

Re: Misc bugs found by using valgrind
by Shachar Shemesh Oct. 2, 2003

Oct. 2, 2003

Michael Günnewig wrote: >Changelog: > Fixed use of uninitialized memory and wrong buffersize (found by valgrind). > > > Michael > > > >------------------------------------------------------------------------ > >--- dlls/avifil32/api.c.SAV 2003-09-20 16:14:45.000000000 +0200 >+++ dlls/avifil32/api.c 2003-09-20 14:46:10.000000000 +0200 >@@ -1009,7 +1009,7 @@ > szFilter[0] = 0; > szFilter[1] = 0; > >- wszFilter = (LPWSTR)GlobalAllocPtr(GHND, cbFilter); >+ wszFilter = (LPWSTR)GlobalAllocPtr(GHND, cbFilter * sizeof(WCHAR)); > if (wszFilter == NULL) > return AVIERR_MEMORY; > > What are we doing to prevent integer overflow on these allocations? Shouldn't we, perhaps, use some wrapper that checks that "cbFilter*sizeof(WCHAR)" is not greater than "MAXINT"? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

3 3

Re: Updated winetests.exe
by Ferenc Wagner Oct. 1, 2003

Oct. 1, 2003

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > On September 27, 2003 07:42 pm, Jakob Eriksson wrote: > >> Do you want a second file generated apart from the mail >> sent to wine-tests-report? (If yes, where should this >> file be sent?) > > I'm not sure I like this idea. Correlating the two files > is potentially problematic, the best thing is if we bundle > this information somehow into the report itself. This way > the results can be interpreted context-free, which is a > good thing. I did not like this idea either, but decided to go with it in the end. First, to generate summaries I have to correlate files anyway, which *is* problematic already, and having a master file could only make it simpler and also make the cause more obvious if some inconsistency is found. Second, we want to include build failure reports, which can be lengthy (eg. compiler logs), and do not seem to belong to the test results. For an example, see how the dsound test build failure is noted on the page. The summary line could also easily be customized. > Maybe we can simply add a flag to the tests so that the > first thing they do when we run them is to output all this > information How is it better than recording the info at the build stage? Since it has nothing to do with the running environment, that would also feel more natural to me. Sure, all the info could be included in the reports, but I see no point in bloating them with too much static info for little (if any) benefit. One more thing, I really do not have the faintest idea about how to integrate this into the WineHQ page. There may be reasons there, too, like eg. the need to notify the system about a new build, which could be done by uploading the information skeleton... Feel free to persuade me, I am not attached. Feri.

4 7

Re: winealsa: improve sound quality for IDsDriverImpl
by Jerry Jenkins Oct. 1, 2003

Oct. 1, 2003

> > If the behavior is subject to change, there is no way you can test > that at configure time. This needs to be a run time check. > You're right. So I put some code in configure.ac, try to compile & run it when configure is executed. If everything is OK, a macro will be defined in config.h.

3 6

Re: PATCH: stop crashes in desktop mode
by Alexandre Julliard Sept. 30, 2003

Sept. 30, 2003

Alex Pasadyn <ajp(a)mail.utexas.edu> writes: > This patch just puts in a simple check that traps this condition so > Wine doesn't crash. I don't know enough about what that code is > supposed to be doing to fix it properly. (This is certainly better > enough on my system though as it longer crashes!) If someone wants to > describe what "should" happen there I can look into really fixing it. The real problem is that we create one X desktop window in each process, while there is only one desktop window in the Windows sense. So anything that depends on the X desktop window to be shared is broken. The right fix is to manage the X desktop in a separate process. -- Alexandre Julliard julliard(a)winehq.com

7 14