Re: [AD] Centering the Allegro window on the Windows desktop

[Tore Halse <gnolam@xxxxxxxxxx>]

On Sat, 22 Jan 2005 23:36:02 +0100, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> On Saturday 22 January 2005 23:24, Tore Halse wrote:
> > Ok, I have a working patch, but I've hit a minor snag - when I try to
> > check the current window's width and height inside adjust_window() all
> > I get is garbage, and I have so far not found a reason why.
> 
> wnd_width and wnd_height should hold the correct values, as far as I can
> see... are you checking those?

Yes. But I'm just getting seemingly bogus values. :-/
 
> > I can
> > easily work around it by inserting two static ints containing the
> > previous width and height (and when I do it works like a charm), but
> > it feels a bit hackish to me...
> 
> Well, it doesn't sound too bad to me... but if it's not nescessary, all the
> better. And one would think that the information is already there
> somewhere...

Ok. I'll make a last push to find out why wnd_width and wnd_height
aren't containing the right values, but if I don't find anything I'll
go ahead and submit the patch with the extra variables added (I had to
add a couple of winapi structures anyway)...

> > (the bonus would be that I get a reliable way to check if
> > adjust_window() has been called before or not, instead of the current
> > implementation that just checks if the window's x position is < 0 or
> > not)
> 
> That may be a good idea to do anyway... the current implementation is
> equivalent because last_wnd_x is (or should be) only negative when it is
> initialized. I'm not sure what happens if you move the window past the
> upper left boundary of the desktop though...

Then it believes the window is to be placed for the first time, which
is why I needed it changed. Checking the static last_w and last_h
variables for != -1 should be reliable enough, unless someone can
think of a reason where adjust_window() would be called with width and
height both == -1...

> At any rate, it looks like shutting down the Windows driver doesn't return
> it to its unitialized state as it should... which is pretty bad IMO.
> 
> I'd say go ahead and add whatever static variables you need yo make the
> code more reliable. If you hit upon some more uncleanness in the code,
> feel free to fix that as well (but provide a seperate patch if you have
> more than one fix).

Ok. I doubt I'll touch any more functions than this one tonight though.
 
Tore

-- 
Feed me a stray cat.