Re: [MiNT] WM_REPOSED implementation

[Xavier Joubert <xavier.joubert@free.fr>]

Hi Olivier, Hi Odd,


Selon Odd Skancke <ozk@atari.org>:
>  A million ways to do this and achieve some kind of result. What I have
> got now works, so why not use that?

Hmmm. Why create a new message when you can work with existing ones ?
...
Perhaps because, as Olivier showed, handling this with existing messages is not
as easy as it first seemed (to me, at least).

> > In your case I know application that don't like it, for example Qed and
> windows
> > dialog in Windom, and there is other, I test only some softwares.
> > In case of Qed, with WM_SIZED it will change with and height to have a mod8
>  or
> > mod16 for this value, and recalculate sliders, then you put WM_MOVED with
> width
> > and height you wan't but not new width and height that application wan't,
> Qed
> > will put it directly but not change his size nor recalculate slider, this a
> > very small problem in fact. For Windom case this is stronger because
> position
> > will be good but size can be totaly wrong, because on WM_MOVED it not look
> for
> > new size, so if window is bigger than dialog, other part of window will not
> > redraw at all, because it correct size only on WM_SIZED. So prefer WM_MOVED
> > before WM_SIZED.

Thanks a lot for your explanations Olivier !

And what if an application tries to snap window position (ie. X and/or Y) to 8
or 16 pixels, as did "tempus word" in the old ST times ? I guess your method
will have the same troubles as mine. Such applications are just far less common
in real world...

>  And all of these problem are solved by the method I use in XaAES.

Now that I see problems I didn't even envisage before, I guess your method is
not so bad. Well, it even looks like the /right/ way to handle this...

The theorical "good way to handling" something often doesn't survive "real
world". :)


Best regards,


Xavier