January 2004 - Wine-Devel - list.winehq.org

Re: Congradulations - windef.h

by Dimitrie O. Paun

On January 1, 2004 08:43 pm, Alexandre Julliard wrote: > You still haven't answered the real question: why > wouldn't it work to have them in winegcc? There's no reason it shouldn't work. However, if we have a lot of defines, it becomes a bit hard to maintain them embedded in winegcc. Also, it would allow people to use gcc directly instead of winegcc (for whatever reason). It would be a wine/ header, and to be honest, I can't see any fundamental reason why we can't have a few well defined wine/ private headers. I'm on the fence on this issue, I don't need the header myself, but I can see a decent argument why you'd want to externalize these things out of winegcc... -- Dimi.

Jan. 2, 2004

Re: #2 - Mdi Win16/32 Split

by Dimitrie O. Paun

On January 2, 2004 10:31 am, Steven Edwards wrote: > Split up the Win16/32 MDI support a bit. Any idea what the status of the Win16/32 split is? What DLLs are still not properly split? -- Dimi.

Jan. 2, 2004

Re: Printing bugfixes

by Huw D M Davies

On Fri, Jan 02, 2004 at 02:47:04PM +0000, Mike Hearn wrote: > Or that this line: > sprintf(buf,"%s,WINEPS,LPR:%s",name,devname); > should be > sprintf(buf,"%s,WINEPS,%s",devname,devname); Yes like that, but you'll then have to add the LPR: bit to devname for the printcap and CUPS cases before the function is called. Huw.

Jan. 2, 2004

Re: REBAR: on a RB_SETBANDINFO message only redraw the rebar if something changed

by Dimitrie O. Paun

On January 2, 2004 10:50 am, Mike McCormack wrote: > This stops IE's toolbar from flickering when moving the mouse over links. Happy, happy, joy, joy... Thanks Mike!!! -- Dimi.

Jan. 2, 2004

Re: #3 - shell32/systray.c

by Mike Hearn

On Fri, 2004-01-02 at 16:07, Steven Edwards wrote: > I am not 100% sure but I think your patch will be enough. We already > have some systray support in our Explorer when running on Windows. Take > a look at running explorer under WINE and see if it will help any. Could you send me an EXE of that, if it's convenient? I have no idea how easy/hard it is to build ReactOS but I doubt it's a configure, make, make install :) thanks -mike

Jan. 2, 2004

Re: #3 - shell32/systray.c

by Steven Edwards

Hello Mike, --- Mike Hearn <mike(a)theoretic.com> wrote: > I have a pretty big patch against the system tray code, and it's > going > to get bigger. Cool. > Hopefully in the next few days I will get time to properly reverse > engineer (if it's not already documented) the interaction between > shell32 and explorer, so we can implement this using a separate > wineshell executable. > > Is there anything you need from us for ReactOS? If the message > protocol > is documented I guess you guys can just implement server support in > your > explorer for it, am I right? I am not 100% sure but I think your patch will be enough. We already have some systray support in our Explorer when running on Windows. Take a look at running explorer under WINE and see if it will help any. Thanks Steven __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 2, 2004

Re: #3 - shell32/systray.c

by Mike Hearn

Hi Steven, I have a pretty big patch against the system tray code, and it's going to get bigger. Hopefully in the next few days I will get time to properly reverse engineer (if it's not already documented) the interaction between shell32 and explorer, so we can implement this using a separate wineshell executable. Is there anything you need from us for ReactOS? If the message protocol is documented I guess you guys can just implement server support in your explorer for it, am I right? thanks -mike On Fri, 2004-01-02 at 15:37, Steven Edwards wrote: > When playing around with a app that uses the systray under ReactOS I > noticed that the comment in Wine is out of date. > > Changelog: > Update the notes in shell32 on how WINE uses the Systray under KDE. > > > > __________________________________ > Do you Yahoo!? > Find out what made the Top Yahoo! Searches of 2003 > http://search.yahoo.com/top2003

Jan. 2, 2004

Re: lParam of WM_CREATE for MDI children

by Steven Edwards

Hello Dmitry, --- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > No offence intended, but I don't see anything useful in the diff: No offence taken. I didnt know if there would be anything useful in there or not. We have been doing a bit of work on MDI because Martin's explorer clone depends on it so I thought we might have already fixed some of the bugs. Quite a few of our developers also use MDI text editors though I dont understand why..... > 1. lots of useless #ifdef __REACTOS__/#endif I agree. We need to better split the Win16/32 stuff in some of the sources we are adopting and abstract some of the code better so Wine and ReactOS can share it without needing these. I will send a patch for this today. > 2. MDICLIENTINFO is allocated twice: in WM_NCCREATE and WM_CREATE. Yes this is a problem too. > 3. again, as everywhere in the ReactOS I see complete misuse of > ansi/unicode > macros vs. real win32 API names. You guys really want to disable use > of macros > based on the UNICODE preprocessor define, like it's done in Wine. > Otherwise > you will get *a lot* of mess and headache in the long run. > > For instance > > SetWindowLongPtr(hwnd, 0, (LONG_PTR) ci); > > what version A or W of SetWindowLongPtr is intended to be used in > this > particular case and in this particular place of the code? Your right. We have the same problem in the controls and I think this causes a good bit of problems for us. Well sorry for the noise, Thanks Steven __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 2, 2004

Re: Printing bugfixes

by Mike Hearn

On Fri, 2004-01-02 at 12:35, Huw D M Davies wrote: > Actually I don't see why we need a different name and devname we > should just use devname for both entries instead. I think it's a > hangover from some old code OK. I'll resend just using devname. > Your patch however looks wrong, you're adding a default printer with > port LPR:LPT1, the spooler will try to print with the command > lpr -PLPT1 which won't work. You really want to set the port to LPT1: You mean in this line? WINSPOOL_SetDefaultPrinter("LPT1","Wine PostScript Driver", FALSE); I don't really understand, sorry. You mean it should be like this? WINSPOOL_SetDefaultPrinter("LPT1:","Wine PostScript Driver", FALSE); Or that this line: sprintf(buf,"%s,WINEPS,LPR:%s",name,devname); should be sprintf(buf,"%s,WINEPS,%s",devname,devname); thanks -mike

Jan. 2, 2004

Re: Printing bugfixes

by Huw D M Davies

On Thu, Jan 01, 2004 at 08:23:20PM +0000, Mike Hearn wrote: > ChangeLog: > - Write out default printer name in the order used by WinME > - Support PRINTER_ENUM_DEFAULT > - Add FIXME for enumerating print providers > > I'd appreciate somebody with a CUPs and lpr setup ensuring the order > change doesn't cause regressions. It appears correct to me, but as the > code worked before even though it looked like it shouldn't I might be > wrong. Actually I don't see why we need a different name and devname we should just use devname for both entries instead. I think it's a hangover from some old code Your patch however looks wrong, you're adding a default printer with port LPR:LPT1, the spooler will try to print with the command lpr -PLPT1 which won't work. You really want to set the port to LPT1: Huw.

Jan. 2, 2004