Hello Przemek, Viktor, Massimo
>hb_gtInfo( HB_GTI_SETPOS, { nMode, nX|nRows, nY|nCols } )
>> hb_gtInfo( HB_GTI_SETPOS, nMode, nX|nRows, nY|nCols )
without array? In the original version I created long ago
HB_GT_INFO structure looks:
typedef struct
{
int iParams;
int iReserved;
PHB_ITEM pResult;
PHB_ITEM pNewVal[ HB_MAX_GTINFO_PARAMS ];
} HB_GT_INFO, * PHB_GT_INFO;
>>> This would be a nice addition IMO.
+1
> hb_gtInfo( HB_GTI_RESIZEMODE, HB_GTI_RESIZEMODE_FONT |
> HB_GTI_RESIZEMODE_ROWS )
>> Yes, I fully agree. As I can see you and Viktor added to GTWVT font
resizing instead of row/col numbers updating when user changes console
window dimensions. Very nice feature and probably more friendly to
existing
Clipper code which is not ready for dynamic screen dimension
modification.
...
...
We should create list of events which can be reported by GTs using
standard INKEY() values. RESIZE is one of such events but we can also
have others like QUIT and/or CLOSE, HIDE, SHOW, FOCUSIN, FOCUSOUT, etc.
>>> May I suggest to mark these extendend event as K_HB_* or
HB_K_* to clearly separate them from regular inkey codes?
Also, we should think (or rethink) the current event
notification feature because we could either use it
for this purpose, or drop it, or make some rules which
to use when, but using them randomly is not a very good idea.
Przemek, I agree with you that we should cover neccessary ( if not all )
events notifications via INKEY(). I also propose to fire user
defined function/block, if one is associated with an event.
I will explain later why it is useful to press my viewpoint.
I have done it in GTWVG but only for few events and with fixed
PRG defined function symbols. I wanted this to be in dynamic way
which unfortunately I could not devise. Then Viktor rescued it
with HB_GTI_NOTIFIERBLOCK. Now I wish to notify all events this way
which at the moment are limited to few.
I disagree with K_HB_* or HB_K_* namespace. Why we want users to
remember one more way of using Clipper syntax. We simply document
the K_* constants. When I introduced K_MBUTTONDOWN ~ K_NCMOUSEMOVE
these were accepted as natural extensions required for GT in
question and now are considered the de-facto standard.
Any programmer looking for extended functionality with certainly
be aware of new constants to take advantage in his applications.
He he/she does not want to he can live with existing code.
Harbour has set few standards and now is the need to extend them
in natural syntax way.
My proposed INKEY codes are:
K_RESIZE 1101
K_RESIZING 1102
K_SETFOCUS | K_FOCUSIN 1103
K_KILLFOCUS | K_FOCUSOUT 1104
K_BEGINPAINT 1105
K_ENDPAINT 1106
K_TIMER 1107
> hb_gtInfo( HB_GTI_MODAL, pGT )
Still unanswered. This is very useful and required feature.
It will unleash true Windows functionality.
> hb_gtInfo( HB_GTI_NOCONSOLE, TRUE )
>> OK though maybe it will be better to implement sth like LOCKAREA
to block console output in specified region.
BTW GTWVT redraw screen using data from base character screen buffer.
GTWVG creates intermediate image so data from screen buffer is written
to this image and to the window. On refresh they are copied from image
to window. We can very easy add such functionality to GTWVT as an option
and it should be even more efficient. Just simply REFRESH/REDRAW will
check if hScrImg exists and if yes then it will draw the screen data
into it like hb_gt_wvt_PaintText(). Inside window procedure we will
change WM_PAINT action and if hScrImg exists then instead of redrawing
screen buffer it will simply copy hScrImg area to window.
It should give the same as GTWVG functionality but faster (we eliminate
double screen buffer redrawing) and much easier to control by user.
Excellent idea. I would like if you take a little time to get
it working. I suspect the way I am handelling the situation in
GTWVG is a little buggy, though I could never locate. I am sure you
will do it in a perfect way.
>> Then it should be quite easy to change GTWVG and instead of replicating
GTWVT code it will simply inherit from GTWVT. Just like now GTCTW can
inherit from any other GT adding CT-Window functionality.
>From the core of my heart I want this. If it happens then time spent
of double efforts can be utilized for better things.
> May be above attributes are required before Window is created, so some
> sort
> of HB_NOSTARTUPWINDOW functionality be implemented.
>> Here we should introduce only one parameter which will
inform GT that it should not show new GT window so after
initializing new GT user can make all necessary settings.
GTXWC has such functionality by default because it always create
console window with 1-st screen update or when user request some
information which needs this window activate. It resolves the problem
but in some GTs it may be hard to implement such functionality.
So I'll add parameter to INIT() methods which will inform GT if
it should show or not console window. When user will want to make
some additional setting then he will ask to not show the window,
set them and finally make window visible. Defining parameters
which should be set before window initialization is not good idea
because such list can still grow up.
>>> Would it be possible to make the initialization on the
first screen paint with GTWVT, too?
I guess this could also (or partially) solve the problem
where currently simple STDOUT/STDERR functions simply
don't work when used with BCC/MSVC. MinGW also behaves
strangely.
This funtionality as 'first screen paint' methodology may
interfere under certain situations as WN_PAINT message is not
under program control. This may be the possible scenario:
1 gt_reLoad( 'WVT', FALSE )
hb_gtInfo( ... )
SetMode( r,c )
SetColor( 'n/w' )
CLS
gt_Show() // Window goes Visible
2 gt_reLoad( 'WVT' )
hb_gtInfo( ... )
SetMode( r,c )
SetColor( 'n/w' )
CLS // Window goes Visible . First paint request
I am not sure how 2nd option can be implemented.
> What do you think having a scrollable area in GT?
>> GTWIN already has such functionality in W2K, XP and later
Windows versions.
> Mobile device and tomorrow internet will require this capability
> Physical area is more small that logical
> Gt window will USE horizontal and vertical scroll bar
> As Physical SET BY HB_GTI_SETPOS (Have 10 row ,40 column)
> As logical SET BY HB_GTI_LAREA (Have 20 row ,80 column)
> The resize will work when Physical and logical are same (default
> behavior)
>> Such functionality without any doubts is usable and I hope it will
>> be added to GTWVT but I would like to leave it for Windows developers.
Can you guide us in right direction. Few hints will be enough.
I think Budyanto implemented some kind of this functionality in
GTWVW. Budyanto ?
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/Proposed-Feature-Set-for-Multi-Window-GTs---II-tp20166811p20166811.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
