Hi Przemek,
On 2009 Oct 6, at 15:13, Przemyslaw Czerpak wrote:
On Tue, 06 Oct 2009, Szak�ts Viktor wrote:
I know this. I need to clarify, by "messed up" I don't
mean the scrollbars and whatnot when using such big
buffer. Instead I mean that the displayed (by Harbour
app) _screen content_ is wrong. It looks like as if
(ctwin) windowing gets confused about current window,
so it's painting to the wrong one and returning size of
the wrong one. But I'll make some real tests later,
could be my app code.
It's possible that there is sth wrong in CTWIN though it should
work correctly - at least I do not see any problems looking at
the code.
If you have some additional extensions then please check if you
do not have some places which may cause coordinates casting to BYTE
or which may calculate screen offset or index in screen buffer using
[U]SHORT value.
Try to reduce number of rows to 255 and check if it helps.
Few years ago I made some tests with very large screen buffers in
MS-Windows console and I've found some bugs in MS-Windows console
code so it's possible that the problem is caused by exploiting them.
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)
4) SetMode( 250, 80 ) // will result in a "no window" situation, where
the app works, but there is
no visible screen. Experienced with GTWVT.
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.
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
Which artificially limits max window size.
Removing the size validation in window creation code fixes
all artifacts experienced in 2). Shall I commit it?
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 leaves 4) on the TOFIX list.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
