> Btw, what does make filter do?
>
> Your post to wine-patches says it's nice an all but it does not say
> what it does.
Try and run it it is self describing. :-)
Since Alexandre didn't apply the Makefile patch, running it is
a little awkwark. Will fix that it later versions though.
Try do:
cd wine
./tools/winapi/make_filter make
You can also give it parameters like
./tools/winapi/make_filter make clean
Warning "make clean" doesn't look that good currently.
PS. It filters the make messages and only display important messages.
It might not always work 100% though, but I will fix problems as I
find them. I wrote it many months ago and have run it from time to
time since, so most issues have been fixed.
The reason I wrote it was that I was irritated that important messages
scrolled of screen.
> If it's nice isn't it worth advertising to the Wine
> developper community?
I had intended to do that if but since I was unsure that Alexandre
would apply my Makefile patch I decided to wait until it could present
a better "user interface". But by all means test it.
> [...]
> > > Most of these are because of the transition to making
> HANDLE a void*
> > > and compiling with STRICT.
> >
> > Yes, I notice this was the case with TIMERPROC casts.
> > However it is no so with the HOOKPROC casts,
> > and yes it is the same with the real Windows headers.
>
> ???
> AFAICS there are two versions of HOOKPROC: one for -DSTRICT and a
> FARPROC one.
Hmm. I looked again and it seems you are right. Must have missed
it somehow. Strange.
> [...]
> > But OK I will try and compile with -DSTRICT and see what happends.
> > IIRC somebody tried that but it didn't turn out so well.
>
> That would be me, probably. I started the conversion to -DSTRICT but
> then other priorities came up and now it's on the back burner. I will
> get back to it eventually but at the current rate it's hard
> to know when
> that will be :-(
> Compiling with -DSTRICT is not that bad: with a relatively simple
> patch it compiles (see attachement). Or at least, it used to.
> But there
> are tons of warnings, which means tons of places that need
> attention and
> possibly fixing. That's where the work is.
OK. Will look at it later.
> The volatile stuff in dplay.h is part of the Windows header, you
> cannot remove it.
No it isn't. I'm not sure why it was added in the first place.
It is neither used by Wine, nor defined by Windows.
In fact only a few strange headers use volitile at all,
and none of them is supported by Wine.
> Most of these are because of the transition to making HANDLE a void*
> and compiling with STRICT.
Yes, I notice this was the case with TIMERPROC casts.
However it is no so with the HOOKPROC casts,
and yes it is the same with the real Windows headers.
> Please don't add typecasts, consider the
> warnings as an incentive to do the right fix...
As you wish, but as I said HOOKPROC can't be fixed with STRICT.
But OK I will try and compile with -DSTRICT and see what happends.
IIRC somebody tried that but it didn't turn out so well.
Oh well, lets see what happends.
> Patrik Stridvall <ps(a)leissner.se> writes:
>
> > No it isn't. I'm not sure why it was added in the first place.
> > It is neither used by Wine, nor defined by Windows.
>
> It is in the Windows headers I have.
It is not in my Microsoft Visual C++ 6.0 header,
but perhaps you have a newer version?
DPlay using volatile seems a little strange,
so I thought is was wrong especially since it
was not in my version, but then I have seen
stranger things. :-)
> > As you wish, but as I said HOOKPROC can't be fixed with STRICT.
>
> Why not?
Because it would be incompatible (warning wise) with Winelib
applications compile with -DSTRICT since Windows doesn't
provide a special -DSTRICT version of HOOKPROC.
The application might pass a FARPROC to it and expect it
to work. Well, of course it works but it would generate
a warning.
Patrik Stridvall <ps(a)leissner.se> writes:
> The make_filter.diff patch is quite nice.
>
> Try it after applying it with by running:
> make filter
I'm not sure about the portability of the wildcard rule. Why don't you
have make_filter call make instead of the other way around? This
would avoid the need for changing the makefiles at all.
--
Alexandre Julliard
julliard(a)winehq.com
> Patrik Stridvall <ps(a)leissner.se> writes:
>
> > The make_filter.diff patch is quite nice.
> >
> > Try it after applying it with by running:
> > make filter
>
> I'm not sure about the portability of the wildcard rule. Why don't you
> have make_filter call make instead of the other way around? This
> would avoid the need for changing the makefiles at all.
Well, make_filter actually calls make already. :-)
Seriously, one reason that I added it to the Makefiles in the
first place is that make_filter doesn't know what version of
make to use. Sure it is called make on almost all systems
and gmake (GNU Make) on most of rest, but since the user
knows and calls "make", $(MAKE) contains the correct "make".
Oh well, I guess just calling make will work on most platforms,
it will on all platforms that I current use. The Wine Makefile is
supposed to be portable so I guess it will have to do.
Patrik Stridvall <ps(a)leissner.se> writes:
> No it isn't. I'm not sure why it was added in the first place.
> It is neither used by Wine, nor defined by Windows.
It is in the Windows headers I have.
> As you wish, but as I said HOOKPROC can't be fixed with STRICT.
Why not?
> But OK I will try and compile with -DSTRICT and see what happends.
> IIRC somebody tried that but it didn't turn out so well.
No it needs a lot of fixes, which is what the warnings are here to
remind us of.
--
Alexandre Julliard
julliard(a)winehq.com
Patrik Stridvall <ps(a)leissner.se> writes:
> * include/commctrl.h,
> include/dplay.h:
> Cleanup/removal of unnessary things that would have made
> winapi_* parsing more complicated.
The volatile stuff in dplay.h is part of the Windows header, you
cannot remove it.
> * dlls/comctl32/commctrl.c,
> dlls/comctl32/tab.c,
> dlls/dinput/dinput_main.c,
> dlls/dsound/dsound_main.c,
> dlls/ole32/clipboard.c,
> dlls/ole32/ole2.c,
> dlls/wineps/ps.c,
> dlls/winmm/joystick.c,
> dlls/winmm/wineoss/midi.c,
> loader/dos/dosmod.c,
> windows/caret.c:
> Fixed some warnings.
Most of these are because of the transition to making HANDLE a void*
and compiling with STRICT. Please don't add typecasts, consider the
warnings as an incentive to do the right fix...
--
Alexandre Julliard
julliard(a)winehq.com
I don't like submitting incomplete code but I may have little choice unless
someone can point me in the correct direction here. As you may guess from
the following, my Windows experience is not that extensive but I think it's
enough to allow me to make sensible contributions.
I am working on correcting the LISTVIEW_DrawLargeItem function, especially
when the item text is large. I have already got most of the way. However
the problem is this.
When a user selects a large icon the text should be written completely (by
calling DrawText with DT_NOCLIP). It is doing so; I can prove it by
resizing the window and I will see the full text being displayed for a
selected item. However when drawing it at the moment of selecting it, the
text is being clipped to the usual two and a bit rows. Presumably this
means that there is a clipping rectangle in the DC or the window that I
need to inflate. Or Do I simply invalidate that rectangle (from within the
WM_PAINT handler!!!).
Any help would be appreciated.
Bill
Lionel Ulmer <lionel.ulmer(a)free.fr> writes:
> Do you plan to implement it or should I do it (be warned though that I can
> work on it only if the weather is bad this week-end :-) ).
I'll do it. I had a version working some time ago, I just need to
adapt it to the new per-thread displays.
--
Alexandre Julliard
julliard(a)winehq.com
