Hi Przemek,
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.
Indeed, especially for WinCE users, on desktop
I expect it to be used rather rarely, although it
may also be useful f.e. when connecting to a remote
GT with higher resolutions.
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.
If possible, I'd like to ask to make this modification,
as I'm almost sure my solution wouldn't be good enough.
BTW, GTXWC also has the same artificial limit.
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.
I've added a strict guard there.
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.
Perhaps other guards could be added to avoid that,
but otherwise this is expected behavior.
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.
Such thing would be nice.
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.
I'd vote for 3. (and 1. as the second choice)
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
