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

Re: Trackbar size fixes
by maxime.bellenge＠laposte.net July 29, 2003

July 29, 2003

A recent patch ( 2 or 3 monthes I think) for trackbars broke them totally in emule. So there was a problem for sure. I have not tested the patch yet to know if it is fixed now. >Odd, I remember doing some work on the trackbar a few months ago (it was >pretty broken). Testing against the native comctl32 from Windows 98 >showed that I got it pretty close - do you have before/after screenshots >for this patch? Perhaps the trackbar looks different in 98 vs 2K. > > >-- >Mike Hearn <m.hearn(a)signal.qinetiq.com> >QinetiQ - Malvern Technology Center Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34/mn) ; tél : 08 92 68 13 50 (0,34/mn)

2 1

dmusic loader question
by Rok Mandeljc July 29, 2003

July 29, 2003

I was planning to (properly) implement DirectMusic Loader, based on example I've found in MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmusic/ht…) But as I don't have enough experience with COM interfaces, I got stuck with implementing IStream interface; how does one declare interface, which consists of two other interfaces (CMyIStream class in example code is actually IDirectMusicGetLoader and IStream at the same time)? BTW, is it illegal to use MSDN examples to implement stuff in wine (EULA...)? -- Rok Mandeljc <rok.mandeljc(a)gimb.org> "All that is gold does not glitter, Not all those who wander are lost; The old that is strong does not wither, Deep roots are not reached by the frost. >From the ashes a fire shall be woken, A light from the shadows shall spring; Renewed shall be blade that was broken, The crownless again shall be king." -- J.R.R. Tolkien

3 3

how cards.dll works
by Jonathan Wilson July 28, 2003

July 28, 2003

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.

2 1

mailing lists down 9am - 7pm CST
by Jeremy Newman July 28, 2003

July 28, 2003

The WineHQ mailing lists were down today. There was a message in the queue that caused mailman to bomb. I found and removed the message (it was a spam). I also stayed in late and upgraded our Mailman to ver 2.0.13 from ver 2.0.0. Let me notice if you notice anything unusual happening in the next few days. Also, I am considering putting a SpamAssassin filter into our Mailman using info from this page: http://www.daa.com.au/~james/articles/mailman-spamassassin/ Anyone against this idea? -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

1 0

Re: Is wine a debugger?
by Dan Timis July 28, 2003

July 28, 2003

Dan Timis wrote: > I am trying to load a security Windows dll that does not run under a > debugger. When I load the dll I get a SIGTRAP, and then wine breaks > in its debugger. > My understanding is that if I run wine as opposed to winedbg I am not > running under a debugger. But, if there is a crash or some other > exception wine will start a debugger. > I sent some memory dumps to the developer of the security dll, and he > said that it behaves like it was running under a debugger. He's > question was something like does wine have an always "on" debugger? Just in case someone else runs into this problem, the fix is to run wine as nt not as win98. Thanks to Alex Pasadyn for the help. Dan Timis Muse Research, Inc.

1 0

Re: first go at some notepad changes
by Dmitry Timoshkov July 28, 2003

July 28, 2003

"Jonathan Wilson" <jonwil(a)tpgi.com.au> wrote: > > A possibility that status bar will change its size behind your back > > justifies the use of GetWindowRect. > ok, good point. > I intend to change it to use GetWindowRect. > But I am going to keep the WM_SIZE stuff in there unless someone can show a > reason why its a bad idea. WM_SIZE is usually sent due to a change in the window size in order to notify window and allow it to do some necessary job. Sending a bogus WM_SIZE might easily mess the thing up since the size you are sending might be not a real window size. -- Dmitry.

1 0

Re: first go at some notepad changes
by Dmitry Timoshkov July 28, 2003

July 28, 2003

"Jonathan Wilson" <jonwil(a)tpgi.com.au> wrote: > +VOID DIALOG_ShowStatusBar(VOID) > +{ > + RECT rcs; > + RECT rc; > + GetClientRect(Globals.hMainWnd, &rc); > + Globals.bStatusBarEnabled = !Globals.bStatusBarEnabled; > + if (Globals.bStatusBarEnabled == TRUE) > + { > + ShowWindow(Globals.hStatusBar,SW_SHOW); > + GetClientRect(Globals.hStatusBar,&rcs); > + Globals.iStatusBarHeight = rcs.bottom - rcs.top; > + SendMessage(Globals.hStatusBar, WM_SIZE, 0, 0); > case WM_SIZE: > - SetWindowPos(Globals.hEdit, NULL, 0, 0, LOWORD(lParam), HIWORD(lParam), > + SetWindowPos(Globals.hEdit, NULL, 0, 0, LOWORD(lParam), (HIWORD(lParam)-Globals.iStatusBarHeight), > SWP_NOOWNERZORDER | SWP_NOZORDER); > + if (Globals.bStatusBarEnabled == TRUE) > + { > + SendMessage(Globals.hStatusBar, WM_SIZE, 0, 0); > + } Do not send bogus WM_SIZE messages, use SetWindowPos instead. Remove iStatusBarHeight from globals and use IsWindowVisible and GetWindowRect when you need to take into account status bar size. -- Dmitry

4 5

Re: [Mono-winforms-list] SWF Examples/Tests
by Mike Hearn July 28, 2003

July 28, 2003

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

1 0

Fw: Child's OninitDialog and Parent's OnKillFocus
by Omer Sahin (Link Bilgisayar) July 28, 2003

July 28, 2003

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?

2 2

RE: Direct access to LPT1
by E Lea July 28, 2003

July 28, 2003

> > 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"

1 0