Hi Pritpal,
I am ready to provide the multi-window in above said manner.
All output/input goes to window selected with
hb_wSelect( [<nNewSelectedWnd>] ) -> nPrevSelectedWnd
though other windows may be viewable by a click.
It will need few more methods to be implemented in core GT.
The skelton will be like:
nWnd := hb_wCreate/Open( nTop, nLeft, nBottom, nRight )
/* NOTE: Base window will ever be 0 */
if nWnd > 0
? SetAppWindow() // 1
SetColor( 'N/W' )
CLS
@ 10,10 SAY [x]Harbour'
@ 12,10 GET someVrbl
READ
Hb_wDestroy/Close( nWnd )
endif
I think the "base" window should always be created by
all GTs, and get the number 0. Maybe you meant the same.
Now suppose base window is clicked by the user while nWnd is in READ
state,
how the GT should respond to it ? We may work on two angles:
1) Make it a modal window so that user is never allowed to click on
base window.
2) Allow user to view the contents of base window then he is to
click again on nWnd.
The second looks more useful, but it will confuse
users. So I'd vote for 1), plus - if possible - to let
users move around any windows, but GTs should not bring
those inactive Windows to front (z order should remain).
If we agree on this I can start working on it. Basic prototype
should be ready within a day or two.
We can guard these method in core with a define also.
Because these methods are additions and interfere nothing with thw
core
code, I suggest to keep these without guard.
It would be best do it right and without bad side-effects,
so that we don't need guards.
I think we should let ppl voice opinions, I'd also like to
hear Przemek's comments before committing anything to the
core, so I'd wait for a bit.
If you'd like to work on this until then, I'm ready to check
it out, but let's please do it outside the SVN.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
