On Fri, 07 Dec 2007, Pritpal Bedi wrote:
> Now perhaps no more static variable is left to be transferred to a strucure
> member.

All GTs which will support multi window API (it does not have to
create many windows physical windows, f.e it can be single program
which will support many terminals connected by IP connection using
GTTRM) should not use static variables or if they are really necessary
sync access to them internally. It's our problem.

> Eventually we will need to tie every console command to a GT, without a GT
> pointer as per now and with a GT pointer for extended usage. For example: 
> SetMode( nRows, nCols )   =>   SetMode( pGT, nRows, nCols )  =>  
> pGT == ( hb_pcount()==3 ? hb_parGT( 1 ) : hb_DetectCurrentGT() )
> And alike for all other GT commands.

What we will do with .prg functions it's different thing. I'm leaving
this decision to other developers. We can add additional parameters
(it does not have to be the 1-st parameter but can be also the last one)
to existing functions or we can define new set of functions window
oriented. If you look at CT3 window functions then you will find that
they are using standard functions and only change current window using
WSELECT(). We can make the same. We can even redirect CT3 window functions
so with GTs which support many console windows WOPEN() will create new
window instead of creating virtual window in current screen area and
adopt old CT3 code to new possibilities without source code modification.

> We may also need to adjust Tbrowse(), Memoedit(), ReadModal() passing them
> pGT as a parameter.

People where using CT3 API without additional functions with window
parameter so it's mot strictly necessary. CT3 overloaded only ALERT()
functions and our API allows to make the same.

> Just an underview of semantics to be employed for multi-GT to be very
> valuable asset to Harbour programmers. I am sure you are having a much-wider
> perspective to infuse everything into this concept.

New functions will make the life easier and I agree that it will be
valuable extension but for me now most important is adding low level
support and I'm leaving the decision about them to you and other
developers.

best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to