On Wed, 07 Oct 2009, Szak�ts Viktor wrote:
> Some more results, this time using GTWVT, as it seems the
> problem isn't GTWIN specific, so:
> 1) SetMode( 80, 255 ) // works as expected
> 2) SetMode( 80, 256 ) // works with display artifact (will check it further
> to eliminate local cause)
> The artifact is slightly different in Win32 and
> Win64 mode.
> In Win32 only current window is messed up, while
> in Win64 mode
> some additional problems are visible, like
> mentioned wrapped menu
> on screen.
> 3) SetMode( 80, 257 ) // not accepted by GTWVT, resulting in default 80, 25
> dimensions. Both in Win32 and Win64.
> (notice however that it would use such bigger
> resolutions if it is
> the system default, this may of course only happen
> with GTWIN)
GTWVT is limited at compile time to:
#define WVT_MAX_ROWS 256
#define WVT_MAX_COLS 256
It's historical limit in very old xHarbour code which can be removed
from current code.
> 4) SetMode( 250, 80 ) // will result in a "no window" situation, where the
> app works, but there is
> no visible screen. Experienced with GTWVT.
I guess it's side effect of code which tries to allocate font which
fits given dimensions. The original code was working in different way.
BTW There is no support for automatic scroll bars in GTWVT and I think
it will be nice to add it.
> Case 3) may be wrong, at least I see no reason why Harbour
> should limit dimensions this way. It's of course possible
> that this is the threshold value where window couldn't fit
> on screen anymore and 256 vs. 257 is just a coincidence.
This limit was taken arbitrary by Peter and it was the size of screen
buffer in very old GTWVT implementation. When I was rewriting GT core
code I removed this limit from GTWVT and I left only #define for
backward compatibility. You can safely remove them but please only
remember to add dynamically allocate in RESIZE() method TCHAR[cols]
string and use in hb_gt_wvt_PaintText() function instes of text[].
BTW there is typo: 'text[ WVT_MAX_ROWS ]' instead of
'text[ WVT_MAX_COLS ]' though without bad side effects because
both defines are equal.
> In case 2) the "desktop" (CTWIN) window creation will fail and
> return -1, and my app isn't ready to handle that, causing
> mentioned "mess". Traces pointed to these lines in ctwin.c:
> #define HB_CTWIN_MAXROWS 255
> #define HB_CTWIN_MAXCOLS 255
It's only for strict CT3 compatibility.
> Which artificially limits max window size.
> Removing the size validation in window creation code fixes
> all artifacts experienced in 2). Shall I commit it?
The only bad side effect will be internal error (out of memory)
if user tries to create very huge window.
> In case 3) it's again an artificial limit controlled by
> #define WVT_MAX_ROWS 256
> #define WVT_MAX_COLS 256
> Do we need this, or should we raise this limit?
This can be eliminated. If we fix the code for automatic font
resizing then limitation by screen dimensions should begin to
work just like in old GTWVT code.
We can introduce minimal font size (i.e. 4x2 or 6x3) to resolve
the problem.
> This leaves 4) on the TOFIX list.
You can disable the code for font resizing by:
HB_GTINFO( HB_GTI_RESIZEMODE, HB_GTI_RESIZEMODE_ROWS )
and it should resolve the problem. I have no idea what is expected
behavior for:
SetMode( 250, 250 )
when HB_GTI_RESIZEMODE_FONT is set. We have few possible choices, i.e.:
1. chose default window dimensions: 25x80
2. resize rows and cols like in HB_GTI_RESIZEMODE_ROWS
3. refuse to create window (SETMODE()->FALSE).
Users using HB_GTI_RESIZEMODE_FONT should chose sth what they prefer.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
