On Wed, 29 Oct 2008, Pritpal Bedi wrote:
Hi Pritpal,
> You never have to look back which GT you are using. You have a feature or
> not can be
> controlled via a single define. I used this mechanism when working with
> Xbase++ and Clipper
> with same sources.
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.
> 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 :-)
> HB_GTI_POS_X
> HB_GTI_POS_Y
What is the difference to HB_GTI_SETPOS_XY and why it cannot be used?
> 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 mean sll these attributes as I outlined before:
> typedef struct
> {
> DWORD dwExStyle, /* 0 */
> DWORD dwStyle, /* WS_THICKFRAME|WS_OVERLAPPED|WS_CAPTION|
>
> WS_SYSMENU|WS_MINIMIZEBOX|WS_MAXIMIZEBOX */
> int x, /* 0 */
> int y, /* 0 */
> int nWidth, /* CW_USEDEFAULT */
> int nHeight, /* CW_USEDEFAULT */
> PHB_GT pGTParent, /* NULL */
> int iCmdShow, /* SW_NORMAL */
> BOOL bDefault, /* TRUE */
> } HB_WVTINIT, * PHB_WVTINIT;
>
> None of the above parameters are Windows Specific. All parameters can be
> exploited
> alsmost in similar way. How a GT take advantage of it depends on its
> capabilities.
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 ;-)
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. 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.
> 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.
> <<<
> BTW we can add to GTWVT thread which will redraw all existing console
> window asynchronously to Harbour code. In such case it will process
> all window messages. This will have one side effect. It will not be
> able to execute .prg code from message loop because it's not HVM thread.
> So please remember that any code which uses notifiers will not be able
> to benefit from such functionality which cannot be enabled for it.
> >>>
> What exactly is its behavior, I could not follow the essense. Can you
> explain how and what will be affected.
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.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
