July 2003 - Wine-Devel - list.winehq.org

Re: first go at some notepad changes

by Dmitry Timoshkov

"Jonathan Wilson" <jonwil(a)tpgi.com.au> wrote: > >> From looking at microsoft examples, said examples send WM_SIZE to the > >>status bar and let it reposition itself. > > > > > > Microsoft examples also tend to be riddled with gotos. I wouldn't use "A > > Microsoft example did this" as justification for anything. > True. > But allowing the status bar to resize itself means that it automaticly > takes into acount things like the font its using for the text and stuff. A possibility that status bar will change its size behind your back justifies the use of GetWindowRect. -- Dmitry.

July 28, 2003

Re: [Mono-winforms-list] SWF Examples/Tests

by Mike Hearn

This will be really great for Wine also, I'm forwarding this on to the Wine list. We really need tests like this, but AFAIK nobody has ever done them. As you can see the Wine widget toolkit does not implement all the features of the MS Windows one (primarily because very few apps actually use them). Nonetheless, adding them should be easy, and it's good to have a refererence like this. thanks -mike On Mon, 2003-07-28 at 11:47, Timothy Parez wrote: > Hi, > > Some time ago I started writing simple tests for SWF control rendering. > At that time I had no way to manage them, but now Duncan has created a > new page on the Mono Wiki where I will add the samples. > > Each sample contains the sourcecode, makefile and screenshots. > I will try to create these samples for each of the controls in SWF > > I will however make seperate projects for controls which use images, > because these don't seem to run on SWF yet. (For example a button with a > background image) > > You can find the wiki page here: > http://www.nullenvoid.com/mono/wiki/index.php/WineSamples > > I hope this helps > Timothy. > > > _______________________________________________ > Mono-winforms-list maillist - Mono-winforms-list(a)lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-winforms-list -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

July 28, 2003

how cards.dll works

by Jonathan Wilson

After finding out that certain things I did when coding cards.dll (such as studying the complete code in a disassembler) mean that any code I write for it a potential "derivitave work", I have come up with a descrition that is (hopefully) detailed enough to enable someone else with windows GDI programming experience to write cards.dll for wine but (hopefully) not detailed enough to be considered a "derivitive work" The folowing files can be made available to whoever ends up working on cards.dll: 1.cards.spec, a ready made spec file for the dll 2.cards.rc, a RC file containing the card bitmaps (which are licenced under a licence that gave permission to use them) and also the card back bitmaps that were sent to me before (to whoever ends up working on this, feel free to modify the images if you dont like them :) 3.makefile.in ready made for the dll and 4.cards.h which contains the publicly documented interface to cards.dll (which I pulled from various info documents found on the net) IANAL but I dont think that any of these could be claimed to be covered by that "derivitave work" thing, if they are, please do tell me. This document explains the workings of cards.dll (version 5.00.2134.1 from windows XP SP1) Cards.dll exports 7 different functions. These are: cdtInit cdtTerm cdtAnimate cdtDraw cdtDrawExt DllMain and WEP cdtInit takes 2 int * variables. It should return TRUE if the initalization was sucessfull and FALSE if it was not. It is a place to do any initalization you require (depending on for example if you want to preload the resource bitmaps or whatever). It should return the x and y size of the card bitmaps in the 2 variables. For the cards I am using, the x size is 71 and the y size is 96 (which just happened to match up with the size of microsofts cards which is good) the main purpose of DllMain is to store the HINSTANCE of the cards.dll to use later when the bitmaps are loaded WEP is a holdover from when cards.dll was a 16 bit dll and doesnt actually need to be implemented (since its never called by 32 bit windows) cdtTerm is where you undo anything you did in cdtInit (such as unloading any preloaded resources) It takes no parameters and returns nothing. cdtAnimate is supposed to handle animations for the card backs but since the backs we are using dont animate, it can just return TRUE (hence why the resource file I wrote returns the windows XP version number since XP doesnt have animated backs either) As for parameters, it takes a HDC, an x and y position and a frame number (each individual microsoft back has a specific number of frames and applictions tend to hard-code these values) cdtDraw basicly calls cdtDrawExt passing the default size of the card bitmaps as the x and y size parameters The real work is done in cdtDrawExt This function takes: a HDC (for the screen window to draw the card on) an X positon and a Y position to draw the card at a card number (cards.h lists the different values) a mode number (again cards.h lists the different values) and a RGB background color What the function does depends on the value of the mode. If the upper bit of md (which is an int) is set, then it shouldnt save and resore the corner pixels (as explained below) modes greater than 7 should (as far as I can tell) do nothing. mode 0 is "draw face card" mode 1 is "draw back" mode 2 is "draw highlighted face card" mode 3 is "draw empty card spot" mode 4 is "erase card" mode 5 is "draw empty card spot but doesnt paint background" mode 6 is "draw red X card" and mode 7 is "draw green O card" all modes use the same "drawing logic" except for mode 4 which doesnt draw any bitmap. You need a resource ID and a raster OP to do the drawing For modes 0 and 2, the resource ID uses this formula resource id equals ((((card number shl 2) mod 0dh) plus ((card number and 3) times 0dh)) plus 1) For mode 1, the resource ID is just the card number For modes 3 and 5, the resource ID is 53 (the resource ID of the empty card spot graphic, also the contant hb in cards.h) For mode 1, the resource ID is just the card number For mode 6, the resource ID is 67 (the resource ID of the card with the red X on a green background graphic, also the contant xb in cards.h) For mode 7, the resource ID is 68 (the resource ID of the card with the green O on a green background graphic, also the contant ob in cards.h) and mode 4 doesnt use any ID since it doesnt draw anything. For the raster OP, all modes use SRCCOPY except for: mode 2 which uses NOTSRCCOPY and modes 3 and 5 which use SRCAND Also, if the mode is 0, the background color is set to white (0xFFFFFF) before drawing. And after drawing, if the card is a red card (resource IDs 0x0E to ox17 and 0x1B to 0x24), it paints over the boarders of the card using PatBlt and the BLACKNESS rasterop. If the mode is 3 or 4, it creates a solid brush using the background color, uses SetBrushOrgEx to set the brush origin to the screen DC origin and then uses PatBlt to paint over the area of the card using PATCOPY. If the mode has the top bit clear (as explained above) and the size matches with the default card size, before drawing, it saves the corner pixels of the cards (the card bitmaps I am using have one pixel in each corner) and then restore them after drawing. To do the actual drawing, you need to load the bitmap resource into memory and load the resulting HBITMAP into a memory DC. You also need to set the background color of the screen DC to whatever was passed in (unless its mode 0, in which case its 0xFFFFFF as explained above). And then, you need to copy the data from the memory DC to the screen DC using either BitBlt or StretchBlt as appropriate. Remeber to free all the GDI resources (bitmaps, memory DCs etc) that you used. And also to restore the background color to whatever it was before you changed it. If the function is a sucess, you return TRUE. If the function is a failure (e.g. a GDI function call fails), you return FALSE. Hoepfully someone can use this information to implement cards.dll in a way that is legally safe.

July 28, 2003

Re: Child's OninitDialog and Parent's OnKillFocus

by Omer Sahin (Link Bilgisayar)

I solved the problem. The problem is not in Wine. The problem was caused by some of our code. Sorry for disturbing. From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> To: "Omer Sahin (Link Bilgisayar)" <osahin(a)linkbilgisayar.com.tr> Cc: <wine-devel(a)winehq.com> Sent: Friday, July 25, 2003 6:13 AM Subject: Re: Child's OninitDialog and Parent's OnKillFocus > "Omer Sahin (Link Bilgisayar)" <osahin(a)linkbilgisayar.com.tr> wrote: > > > In a CFormView , I create and display a CToolbarDialog. I use DoModal to > > display the dialog. > > A control (in Parent Windows) 's OnKillFocus event is called AFTER the > > child dialog's OninitDialog. > > This seems meaningfull to me, but in my Windows 2000 professional machine, > > child's OninitDialog is > > called BEFORE parent control's OnKillFocus. What should be done to correct > > this problem? > > If you could create a really small test case (no MFC, pure Win32 API) and post > it here, somebody would have a look. > > -- > Dmitry. >

July 28, 2003

Profiling wine

by Mike Hearn

Hi, Is there any way to get measurements of where Wine is spending most of its time? I have a problem where typing text into the WebBrowser control is incredibly slow, but don't really have a clue where to start looking. A profiling tool would be handy about now...... thanks -mike

July 28, 2003

Re: first go at some notepad changes

by Jonathan Wilson

Troy Rollo wrote: > On Mon, 28 Jul 2003 13:34, Jonathan Wilson wrote: > >> From looking at microsoft examples, said examples send WM_SIZE to the >>status bar and let it reposition itself. > > > Microsoft examples also tend to be riddled with gotos. I wouldn't use "A > Microsoft example did this" as justification for anything. True. But allowing the status bar to resize itself means that it automaticly takes into acount things like the font its using for the text and stuff.

July 28, 2003

RE: Direct access to LPT1

by E Lea

> > The plotter doesn't need a specific driver - it doesn't even have one. In > > Windows it uses any old printer driver just to open the printer port, then > > sends commands to the plotter through the printer driver. > > > > Should it not be possible to do this with Wine? Possibly not with CUPS > > though... > Well that should work with cups too, you need to configure a printer > with model "RAW". It doen't - I get a an error saying "Call to StartDocPrinter failed"

July 28, 2003

Re: first go at some notepad changes

by Troy Rollo

On Mon, 28 Jul 2003 13:34, Jonathan Wilson wrote: > From looking at microsoft examples, said examples send WM_SIZE to the > status bar and let it reposition itself. Microsoft examples also tend to be riddled with gotos. I wouldn't use "A Microsoft example did this" as justification for anything.

July 28, 2003

Re: cab_F_00: codename: "whee"

by Dimitrie O. Paun

On July 27, 2003 11:32 pm, Gregory M. Turner wrote: > I dunno I guess I thought maybe cabinet.dll would just be silent in this > case and too easy to miss as a culprit... maybe it's stupid. I guess if you think they will signal real ERRes most of the time, and your confidence in the code is low, they kinda make sense. I'm just a bit worried about the number of ERRes we produce... -- Dimi.

July 28, 2003

Re: first go at some notepad changes

by Dimitrie O. Paun

On July 27, 2003 11:34 pm, Jonathan Wilson wrote: > And also, said examples store the status bar height for later use > (presumably because calling IsWindowVisible and GetWindowRect multiple > times is slower than saving it and reusing it later) I'd have to agree with Dmitry -- this looks like the sort of premature optimization that complicates things needlessly. I had the same gut reaction -- just use GetWindowRect when you need that info. -- Dimi.

July 28, 2003