Hi Pritpal,

Hi

There are three constants in hbgtinfo.ch, viz.,

HB_GTI_GETWIN
HB_GTI_SETWIN
HB_GTI_NEWWIN

These messages are in the context of CTWIN, if I am not mistaking.
The similar type of constants I need for GTWVT.

HB_GTI_GETWINDOWHANDLE
HB_GTI_NEWWINDOW

Can we use the existing names HB_GTI_???WIN?

HB_GtInfo( HB_GTI_MESSAGE, { nMessage | HB_GTM_*, xSomeValue } ) ->
xOldValue
I feel this is multi platform and will eliminate the need of so
many functions which one will be writing to do certain things.
Local GT will be knowing what these values means and how to react to them.
It is another level of abstraction.

HB_GTI_NOTIFIERBLOCK - GT to APP
HB_GTI_MESSAGE - APP - GT

Opinions?

IMO it would be even more simple to use this:
hb_gtInfo( HB_GTI_SPECFEATURE, <HB_GTI_WVT_EXTRAFEATURE>[, xNewValue ] ) -> <xOldValue>

But the fundamental problem with both is that
we're again introducing a way to make the GTs
behave differently. So it kind of ruins the concept.

If we already have such stuff in common GT,
maybe it'd be better to switch them to the above
method, but I feel this would just give way for
lots of GT specific features, so overall I think
it creates more problems.

BTW, the third method, and the one used for RDDs
too, is to simply use hb_gt_wvt_<extrafeature>()
kind of calls. This has the downside that app
code needs to use #defines to exclude such call
if the GT is not linked (just like for RDDs).
The conceptual problem remains here too though.

Brgds,
Viktor

_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to