Hello Przemek
<<<
And Pritpal wants to remove it and simply inherit from GTWVT.
IMHO it's good idea.
>>>
Exactly.
GTWVG is 100%GTWVT + Redirecting few more messages and extending the
structure a little bit.
GUI calls and elements are totally independant from core GTWVG.
So instead of updating GTWVG core whenever there is a change in GTWVT is a
pain.
There are two possibilities to resolve it:
1) Some mechanism to inherit the GT and add only methods which change the
basic behavior.
Something like :
HB_GTCLASS GTWVG INHERITS GTWVT
Method WndProc( m,n,w,l )
Method ProcessMessages( pWVT )
and like. I do not know can this be implemented or not, just a thought.
2) All additions in GTWVG.C and GTWVG.H be inserted in GTWVT.C and GTWVT.H
under some define, e.g., #ifdef __GTWVG__.
Though first solution will allow GT development scaling to next level.
<<<
Now the proposed extensions.
We already have in GUI based GTs extensions which are not portable
to other GTs. F.e. you added font resizing to GTWVT when user changes
the window size (just like in GTALLEG). I like this feature but it's
not portable to other GTs like GTTRM/GTCRS/GTSLN which have to accept
that terminal changes its state without our control and can be resized
by user what usually changes number of rows and columns so it's compatible
with previous GTWVT behavior.
There are some differences between GTs and we cannot hide all of them.
>>>
You have summed up the whole point of my proposals.
Compatibility means the code written is "compilable" with every
GT, and not "behavable similarly". You can link tests/wvtext.prg
( targetting pure console output ) with GTWVG without problems.
GUI extensions comes into play only when called in the application, not
in the core code.
<<<
In this case we talk about three features:
- passing style to console window so it can be tuned to look and behave
like other OS windows
- bounding console window with other group of visible objects or desktops
- setting initial possition for new console window.
>>>
Plus a few more attributes, all generic.
<<<
For me all of them are important just like important is font selection
or color palette setting. In some situations even much more important
because without them it may not be possible to create console window at
all in some environments, f.e. in XWindow I can display console window
on different desktops, different XServers and different computers. If it
will not be possible to control some of such local to given GT features
then it may not possible to use some GTs. F.e. I can have application
which works on remote server without any display adapter as daemon (service
in Windows technology). On request this application can create console
window using GTXWC on my local computer giving some functionality like
online configuration. If I do not introduce some new features to GTXWC
which are not available in MS-Windows/DOS world then GTXWC will not be
usable for me. I will have to make copy of GTXWC for my own use to
change only few lines just like now GTWVG is copy of GTWVT with some
extensions.
>>>
Absolutely true observation.
<<<
It's not good situation with also introduce other problems.
Extensions will appear locally and will be strictly bound with given
GTs so code using them will not be portable ot other GTs and platforms.
We should try to reduce such situation and if possible try to define
some interface which can be implemented also in other GTs which have
similar possibilities. If sth cannot be well emulated by all GTs then
we should add option which will allow to check GT capabilities from
user code. F.e. just like now we can call hb_gtInfo(HB_GTI_ISGRPAHIC)
to check if GT can operate on pixels or only on characters.
It does not mean that we need all extensions in core code but we should
allow to write 3-rd party / contrib code which can use core GTs as base.
>>>
IMO if all calls (CUI,GUI,else) are routed via GT core, it is more portable.
Let's take an example: Windows resizing is retrieved via HB_K_RESIZE event
and is routed in the core. Now appln code
if LastKey() == HB_K_RESIZE
// if you are in browser navigation loop
#if defined(__GTWVG__) .or. defined(__GTWVT__)
// Reconfigure browse to reflect to the situation
#else
// Do nothing
#endif
endif
OR
if LastKey() == K_F10
#ifdef __MT__
// Execute a new thread, execute hb_gtReload()/hb_gtCreate() and
execute the root function
#else
// Just call the root function
#endif
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.
<<<
In this case I see why Pritpal wants to introduce such extensions
and seems that the final results will be very interesting. Anyhow
I do not like that they are such strictly hardcoded to be MS-Windows
API parameters. In such case we will have similar set of parameters
but incompatible also for XWindow and maybe MacOSX or OS2 if someone
create GUI GTs for these systems.
So I suggest to define what elements we want to set and use definitions
with some meaning defined by us which then can be used with other GTs.
So now we need:
HB_GTI_WINDOWSTYLE
We should also define our own styles HB_GTI_WS_* instead of using
MS-Win constant values if we want to make this feature portable to
other platforms. Please also do not start with whole list of all
possible styles in some platform but use only these ones which are
necessary and will be implemented and fully supported.
As I can see we already have:
HB_GTI_SETPOS_XY / HB_GTI_SETPOS_ROWCOL
Looks that it's enough for basic window positioning.
Pritpal, what else do you need to control window creation?
>>>
HB_GTI_WINDOWSTYLE
HB_GTI_WINDOWEXSTYLE
HB_GTI_POS_X
HB_GTI_POS_Y
HB_GTI_PARENT
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.
<<<
I think that predefined window classes can be covered by our
styles (and it will be good for portability) but maybe I'm wrong.
>>>
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.
<<<
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.
Thanks for the detailed analysis.
You came very close, even beyond, my imagination.
Budyanto, you might be having same thoughts I outlined above.
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-tp20205973p20236458.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
