Hi Pritpal,
NOTE: Borders will be visible when resizing as is as it cannot be
controlled
programatically unless the solution I had offered very begining ( by
changing
windows visual effects progrmatically ).
Once the user releases the mouse button the window is refreshed. It is
exactly like if drag effects are turned off except for that it
displays the
border.
But certainly continuous repainting is reduced to a single call.
After you change it got a little bit better, but now
I'm getting black stripes on a grey background, and the
screen content gets cleared when mousing over it. Again
I think it's wrong in two ways, a) from a UI usability POV,
as the user have to do trial and error to get the desired size.
(press mouse button -> start moving it around -> release
button -> see the result (which is not the exact rectangle
set by him for 99% of cases) -> start over), b) the artifacts,
which ruins the "quality feel".
So, problem is that this effectively removed interactivity
feel, and the user will have no idea how the resized
window will look like. If we cannot do anything smooth
looking I think the current GTWVT solution is - if not
perfect, but - fine.
Much more important would be to remove unnecessary _internal_
resize, font size, etc API calls made by GTWV*, when there
is no _actual user interaction_, like startup, or simple
resize initiated by app code maybe. I guess this is what
Przemek was also pointing at. The other, even more important
problem is WinCE incompatibility.
[ Many Win API calls while resizing is not a big problem,
because it doesn't make it particularly slow, it's
a relatively rare event anyway and always initiated by the
user, while he's not doing anything else naturally, and it
works perfectly fine through a remote terminal connection
already. ]
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour