[Harbour] 2007-12-07 11:39 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

[Marek Paliwoda]

Pritpal,

> <<<<<<<<<<
> Perfect explanation :), however how about using a "paralell API" ?
> 
> Instead of
> 	SetMode( nRows, nCols )
> one could use
> 	winSetMode( pWIN, nRows, nCols )
> (or something like that)
> 
> Do you see any problem with it ?
> 
> No problems if I intend to and have required resources to change 500,000+
> lines of code. Leave SetMode() example as it is only used at once or can be
> omitted altogether. Let us take example of :
> 
> @ 12,10 SAY 'Hello World' COLOR 'W+/B'
> 
> How we will force this to paint in a particular window? There are the
> possibilities.
> 1) @ 12,10 SAY 'Hello World' COLOR 'W+/B' WINDOW pWin
> 2) hb_WSelect( pWin ); @ 12,10 SAY 'Hello World' COLOR 'W+/B' 
> 3) @ 12,10 SAY 'Hello World' COLOR 'W+/B' ; // GT detects which window has
> the display focus and substitutes pWin parameter.

The solution could be a new preprocessor directive :
@ 12,10 SAY 'Hello World' COLOR 'W+/B' WINDOW pWin => HB_DevOut(),
however read below.

> OR you wish to tie a Tbrowse to a pWin. In such case all GT commands in
> TBrowse, e.g., DispOut(), DevPos(), etc are passed the pWin/pGT parameter
> along ensuring that Tbrowse is displayed ever in correct window.

This indeed seems to be an interesting problem.
TBrowse internally uses a standard API, which does
not know anything about in which window it has to
display its contents. It would have to be rewritten
to use a parallell API and to store a pWin in which
it started. You got the point with your proposition :).

-- 

Marek


----------------------------------------------------------------------
Zamow u Donalda CUD na mikolajki!
Kliknij >>> http://link.interia.pl/f1ca3