Victor
<----------------->
cOldGT := hb_gtSelect( "GTWIN" )
DispOutAt( 10, 10, "hello1" )
DispOutAt( 11, 10, "hello2" )
...
hb_gtSelect( "GTWVG" )
DispOutAt( 10, 10, "hello3" )
DispOutAt( 11, 10, "hello4" )
...
hb_gtSelect( cOldGT )
<----------------->
Perhaps you are viewing multi-GT from another angle.
It is MULTI-WINDOW SINGLE-GT approach, if I am not missing
something, which
has real-life usage. In an application there is never a need to open
two
TYPES of WINDOWS but windows performing two TYPES of TASKS. The real
need is
how those windows respond to events. For an example, one may need a
window
for punching an invoice and another window displaying, in scrolling
mode,
catalogs or another information. If we take above approach, then
output/input only occurs in the window we have selected as
hb_gtSelect( pGT
== nWindow /*"GTWVG"*/ ). What happens, in the middle of execution
of a
piece of code, user clicks on another window executing another code.
I am of the opinion that current api must not be changed at command
syntax
but must be extended to support multi-windows. On compiler level
what needs
to be changed has to be changed just like what Przemek has done with
the
core GT.
I am not sure enough to what extent I am been able to explain my
viewpoint.
Please take this as a quick, brief explanation.
Okey, I see what you mean, but my opinion is still the same regarding
window selection. Window selection should be a separate command IMO.
We're not extending (which essentially means changing) existing CA-
Cl*pper
functions as a rule in Harbour.
nOldWnd := hb_gtwvg_WSelect( nDetails )
DispOut(...)
hb_gtwvg_WSelect( nMyOtherWindow )
DispOut(...)
hb_gtwvg_WSelect( nOldWnd )
Since apps are usually using one window at a time, switching
between them this way is not a performance or coding problem.
As an alternative, you can also implement such thing locally
for your GT:
hb_gtwvg_DispOut( nMyWindow, "hello" )
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
