On Sat, 08 Dec 2007, Marek Paliwoda wrote:
> Perfect explanation :), however how about using a "paralell API" ?
For MT programs it will be enough it current window pointer will
be stored in thread specific data. In out case it will be part
of thread stack structure so each thread calling current screen
functions (without pWIN parameters) will operate on different
window because inside these function pointer to current window
will be thread specific and retrieved from thread HB_STACK
structure.
> Instead of
> SetMode( nRows, nCols )
> one could use
> winSetMode( pWIN, nRows, nCols )
> (or something like that)
> Do you see any problem with it ?
I do not see anything wrong with alternative set of screen
functions which will accept pointer/handler to GT context
but this is necessary for easier using multiple windows in
single thread to eliminate setting/restoring current window.
F.e. instead of:
pOldWin := winSelect( pNewWin )
setMode( nRows, nCols )
winSelect( pOldWin )
it will be possible to use:
winSetMode( pNewWin, nRows, nCols )
But we can also intorduce yet another solution. F.e. I plan
to add support for overloading alias operator, f.e. for:
oVal->([some code])
if oVal overloads alias then oVal specific method will be
executed to set and restore workarea. But what will be done
inside will only depend on user code. This code may change
current workarea but also current window so it will be possible
to make:
oWin->( setMode( nRows, nCols ), devOut("Hello !!!") )
and of course we can also define TWINDOW class which will have
all necessary methods like SETMODE(), DEVOUT(), SETPOS(),
SETCOLOR(), SETCURSOR(), MAXCOL(), MAXROW(), COL(), ROW(), ...
which will switch to valid window before calling corresponding
functions and use this class in RTL code for screen output.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
