Hello Viktor
<<<
If you don't mind I'd remove the symbol based
methods, as it doesn't seem to be std core
language way to control such things. It causes
problems where other libs define this symbol for
example.
>>>
I do not mind. But "HB_NOSTARTUPWINDOW" is a must as there is no way to
force it at the time of initialization of GT. It serves a great purpose.
Rest no other symbol is required, so you removed them.
Please readd "HB_NOSTARTUPWINDOW".
<<<
Since IMO the whole point of GTs is to give an
abstraction level above the very different terminal
types, we should apply this level of abstraction
to the callback event, too. Meaning that I think
we should remove any "wparam", "lparam" refs,
as the beauty of core Harbour is that it doesn't
deal with this level of system specific stuff
diirectly. This stuff is to be implemented outside
of the scope of the GT core. I'm also not sure
if this is a good way to pass mouse/keyboard events
in a generic way, some GTs may not work like this,
plus we'd rather need a core key/mouse pipeline,
I think there has been discussion about this, but
it's still not implemented (I'm not sure).
>>>
It is matter of terminology. We can give generic names to them and generic
names to parameters. How a method is implemented is local to the GT in
question. One can find a way to simulate the same behavior another may not.
But we need SLOTS in the core, otherwise it becomes impossible to extract
full power of a protocol.
<<<
So the idea is: Let's pass _abstracted_, _high level_
and platform neutral messages to these callbacks
to notify about these the underlying app. And we
need only one notifier block. Any user data may
be passed through the callback, so IMO we don't
need a duplicate way to do this.
hb_gtInfo( HB_GTI_NOTIFIERBLOCK, {|nEvent, xPar|
myEventCatcher( nEvent, xPar, myappdata ) })
>>>
I agree on the _abstracted_, _high level_ concept. But to achieve this we
also need a mechanism.
Per your example:
hb_gtInfo( HB_GTI_NOTIFIERBLOCK, {|nEvent, xPar| myEventCatcher( nEvent,
xPar, myappdata ) })
Under this construct how do GT will know about <nEvent> and will fire this
slot at what point of execution ?
The body of the GT execution is different with each implementation. In one
GT some event, e.g. HB_GTE_CLOSE needs to be executed where Key Press is
processed and in some other (GTWVT) when X button is clicked. How you will
know that GT is advised to react to this event?
I agree with abstraction, so we can provide generic names, but slots and
dispatching needs to be in the core.
I implemented all these methods in GTWVG but from outside the core. My
viewpoint is to enrich GT. In the past many methods were introduced which
belonged to a particular GT only and they still exist in the core.
All we need is to define symbology and its behavior and forget about how a
GT will implement them. It will lift a lot of restrictions.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/2008-06-08-16%3A03-UTC%2B0800-Pritpal-Bedi-%28pritpal%40vouchcac.com-tp17724278p17726667.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
