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
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/2008-10-28-12%3A53-UTC%2B0100-Przemyslaw-Czerpak-%28druzus-at-priv.onet.pl%29-tp20205973p20239566.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
