Hi Pritpal, Przemek,
> I guess you want to create nested windows and you need parent window
> handle. Fine but what protection do you plan to make against destroying
> parent window with subwindow active? Can you define some expected
> behavior for such situation? What is real MS-window behavior in such
> case? Does it destroy all subwindows automatically? What happens if
> you will try to use child window handle after closing parent?
In the area of window's parent and modality, I'd like to share the convention
in gtwvw as follows.
(I hope it might be usefull in deciding the policy to the general API here.)
/*OpenWindow(row1, col1, row2, col2, ;
* nStyle, nParentWin)
*rowx and colx are relative to MAIN WINDOW (not current window!)
*rowx and colx are used for:
*(1) positioning window to its initial position,
*(2) determining the size of the window
*(3) become the new maxrow() and maxcol() in Standard mode
*(4) saved into RowOfs and ColOfs in MainCoord mode
*
*nStyle is window style
*
*nParentWin is parent window of the new one we're about to open.
* default is: current window (in Standard Mode)
* topmost window (in MainCoord Mode)
* If you want the new window to not have parent,
* pass -1 as nParentWin.
*
*returns window number if successful
*returns 0 if failed
*/
Let's forget about the coordinates for now (our discussion haven't got there
yet).
Further explanation regarding nParentWin is as follows:
nParentWin = 0: the parent is the Main Window
nParentWin = n: the parent is the n-th window
nParentWin = -1: no parent (the window is of the same level as the Main Window,
and it will present in
the taskbar as the Main Window)
When a window is open with a parent, user is not allowed to switch focus to the
parent. (The
subwindow is always on top of the parent.) This is similar to the "modal"
behaviour in Windows, but not
exactly the same.
In gtwvw window must be closed in reversed order: window #n, #n-1, ..., #1
This convention was made because of the limitation of the model (bad design).
IMHO the expected behaviour of closing window is to the deny the close
operation if it has a
subwindow.
Sorry I can only describe what's seen from programmer perspective (the expected
behaviour), since I
don't have technical knowledge to the new GTAPI.
regards,
budyanto
On 29 Oct 2008 at 18:51, Pritpal Bedi wrote:
>
> Przemek
>
> <<<
> Conditional compilation does not resolve all problems and in some
> situation it may not be enough. We should always try to reduce
> and differences when possible.
> >>>
>
> ok.
>
> <<<
> > HB_GTI_WINDOWSTYLE
> > HB_GTI_WINDOWEXSTYLE
>
> Why do you need both?
> I know CreateWindowEx() parameters but I'm interesting in
> functionality you want to implement so I can try to reproduce
> it in GTXWC. I'm not interesting in writing Mini WINE to emulate
> MS-Windows API :-)
> >>>
>
> Function Main()
>
> do while .t.
> nKey := Inkey(0)
>
> if nKey == K_F10
> hb_ThreadStart( {|| MyFunc() } )
>
> elseif nKey == K_ESC
> exit
>
> endif
> enddo
>
> Return NIL
>
> Function MyFunc()
> Local pGT, pGT1
>
> pGT := hb_gtCreate( 'WVT' )
> SetColor( 'N/W' )
> CLS
>
> USE TEST SHARED
> // BROWSER CODE
> Navigation Loop
> if nKey == K_F2
> pGT1 := hb_gtCreate( 'WVT' )
> hb_gtInfo( HB_GTI_RESIZABLE, .F. )
> hb_gtInfo( HB_GTI_WINEXSTYLE, HB_GTSTYLE_MODAL )
> hb_gtInfo( HB_GTI_WINSTYLE, HB_GTSTYLE_NOTITLEBAR )
> hb_gtInfo( HB_GTI_SIZE, 7, 40 )
> hb_gtInfo( HB_GTI_SETPOS_ROWCOL, 10, 10 )
> hb_gtInfo( HB_GTI_PARENT, pGT )
>
> SetColor( 'W+/W' )
> CLS // I do not want it to be visible
> automatically
> hb_gtInfo( HB_GTI_SHOWWINDOW ) // so this command
>
> Alert( 'Continue next process?', { 'Yes','No' } )
>
> hb_gtDestroy( pGT1 )
> hb_gtSelect( pGT )
> endif
>
> What I am trying to achive is to create a modal window pGT1 on top of parent
> pGT. This can be achieved in Windows as:
>
> CreateWindowEx( WS_EX_DLGMODALFRAME,
> ...,
> ...,
> dwStyle with flag to off titlebar and
> sizebox,
> x,
> y,
> width,
> height,
> hWndParent,
> ...
> ...
> etc )
>
> x,y,width,height can be adjusted after window is created.
> But WS_EX_DLGMODALFRAME is not possible to be assigned afterwards.
> To make a window true modal and yet to retain its original windows nature
> it has to be CREATED with these flags. It also needs hWndParent.
>
> In next evolution of the GT we may need this functionality, so am I
> emphasizing.
>
> My goal is not to introduce Windows constants, we can have our own, but is
> to
> have slots to achieve the required functionality.
>
>
> <<<
> > HB_GTI_POS_X
> > HB_GTI_POS_Y
>
> What is the difference to HB_GTI_SETPOS_XY and why it cannot be used?
> >>>
>
> It can be. Right now it just sets the windows coordinates but does not
> retain in
> structure member. We need to retain it prior to executing CreateWindowEx().
>
> <<<
> > HB_GTI_PARENT
>
> I guess you want to create nested windows and you need parent window
> handle. Fine but what protection do you plan to make against destroying
> parent window with subwindow active? Can you define some expected
> behavior for such situation? What is real MS-window behavior in such
> case? Does it destroy all subwindows automatically? What happens if
> you will try to use child window handle after closing parent?
> I do not know real MS-Win behavior but IMHO such functionality should
> be started in parent console window which can send its own handle to
> child window registering this child in its own structure so it can be
> dealocated automatically when parent window is closed. Otherwise we will
> create easy way to create set of dummy/wrong OS handles which may cause
> different bad side effects when accessed. GPF is the very optimistic in
> such case but there are also possible much worse situations. F.e. in
> *nixes all devices use common handle system so you can cause DBF file
> corruption if you will write to device closed without your knowledge
> and closed handle number was reused by RDD inside USE command exected
> later. It may happen with application tested for many month/years by
> different users but user#1001 hit [X] in the wrong moment and the
> hardly repeated black scenario happened and very important data were
> lost.
> So it's extremely important to always protect core code against such
> situation even if it's very small chance for such spectacular crashes.
> Here we will also need at least some basic protection.
> >>>
>
> I need the parent window handle just to create a modal window. A modal
> window
> never allows to access its parent any way, that is why it is called modal.
> I do not know the window handles detail in other nixes, but in Windows it is
> absolutely safe. It is just a handle to a Window returned with
> CreateWindowEx()
> function and has nothing to do with any other functionality.
>
> You know better about all this stuff, so your judgement is ultimate.
>
> <<<
> The idea is not MS-Windows specific but parameters you requested are
> nearly _exactly_ MS-Windows CreateWindowsEx() function parameters.
> Would you like to see parameters used by XWindow? In summary they
> are much better because in XWindow protocol problems with portability
> and remote access and using different hardware and OS on client and
> server side are already resolved so we will not have to reinvent the
> wheel in few cases. So maybe I'll define them as Harbour standard and
> you will try to write emulation layer for MS-Windows ;-)
> >>>
>
> This is what I am advocating. I said before that this is a pseudo code,
> actual code will be different. See above.
>
> <<<
> It's a joke of course but should illustrate the problem when you try
> to make sth strictly bound with given OS.
> Please also do not forget about yet another functionality. As long as
> it will be possible to recreate all application windows from scratch
> using only our own meta description then it will be possible to have
> GTNET in application running on the server and native GT client on user
> side.
> >>>
>
> this is really exciting to me. I have my own terminal but that is
> based on screen buffer and key strokes. GTNET will be the project I will
> be most interested in.
>
> <<<
> When user computer crashes then it's enough to connect to the
> server again and restore all windows using information from server.
> In the moment when you introduce hidden bindings between GT windows
> not visible for our GT layer you are loosing such functionality.
> It would be very nice if you can develop GTWVG keeping it at least
> on very basic level so this GT will be fully functional for remote
> access.
> >>>
>
> For sure my goal is the reusing all my exiting code without any changes.
> My existing Clipper code. So till today my effort has been directed to
> achieve this goal, and I have been fairly successful.
>
> <<<
> > This is ONE most important attributes but attracts few more parameters,
> > especially pGTParent.
> > Put together GT will be able to create MODAL dialogs, CHILD dialogs, etc,
> > list
> > is endless.
>
> See above. Passing OS handles directly does not resolve fully the problem,
> is very danger in some cases and can block future extensions. I want to
> have such functionality but we cannot add sth like that to core code as is
> without defining relations between our own GT window structures and
> protection
> code.
> >>>
>
> Your whole explanation about OS handles has gone out of my knowledgebase.
> Please pardon me if I could not understand all you explained, poor me.
>
> <<<
> Now GTWVT window is not refresh automatically but only when thread
> which created call some GT functions.
>
> It has some bad side effects,
> f.e. when your primary code is doing sth and the console window
> is overloaded by some other screen object and needs to be refreshed
> then it's not refreshed until your code will not execute some GT
> function. It can be very easy resolved. Inside GTWVT we create
> thread to refresh console window and collect incoming keyboard/
> mouse events. This thread will be processing window messages and
> our own HVM thread will never execute hb_gt_wvt_WndProc() but it
> will only send notify messages from REFRESH method (BTW in very
> similar way to current code). It should increase the application
> performance and will also resolve some other problems like fast
> HVM notification about DEBUG or CANCEL keys.
> Anyhow the thread serving GTWVT window can sends only very
> simple notification to HVM thread which will not force additional
> synchronization code using some strictly defined memory variables.
> For sure it will not be able to execute .prg code from hb_gt_wvt_WndProc()
> when HVM thread is also executing .prg code. Such functionality is
> possible only in MT HVM after allocating by thread on HVM stack
> (hb_vmThreadInit()) so it will not work in ST mode and even in such
> case the code executed by GTWVT thread will work simultaneously to
> main HVM thread without stopping it so it will behave differently
> then now. F.e. it should be protected against GT reentrance and
> interaction with foreground thread.
> >>>
>
> Implement this feature and we can see how it interacts with the
> realtime usage. For sure it is noval concept and will provide a big boost
> to the GT implementation.
>
> I always wondor how deep knowledge you have, almost on every aspect
> of the internals... The other day we ( me and Francesco ) were trying
> to estimate your age based on your knowledge and came to the conclusion,
> based on owr own knowledgebase and age, and reached to an agreement that
> it must be near 155 if not more.
>
> Regards
> Pritpal Bedi
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
