Hi Pritpal,
I disagree with K_HB_* or HB_K_* namespace. Why we want users to
remember one more way of using Clipper syntax. We simply document
the K_* constants. When I introduced K_MBUTTONDOWN ~ K_NCMOUSEMOVE
No one has to remember anything, since this
will be a brand new feature to learn. Namespaces
are still needed for the same reason we've been
using them in all other places.
For example I have some K_* codes already defined
locally, other developers may also have such, and
it would be nice to avoid possible collisions with
existing user code. Not to mention how more easy
is to find non-portable Harbour code by grep-ing
to HB_K_* names instead of trying to find them
one by one.
Lastly, these won't be key presses anymore, so
it's good to make a difference in the name too.
I'd suggest K_HB_* prefix for Harbour extensions,
and K_HB_EVENT_* in case we opt for extending
keypresses with such stuff.
these were accepted as natural extensions required for GT in
question and now are considered the de-facto standard.
Any programmer looking for extended functionality with certainly
be aware of new constants to take advantage in his applications.
He he/she does not want to he can live with existing code.
Harbour has set few standards and now is the need to extend them
in natural syntax way.
My proposed INKEY codes are:
K_RESIZE 1101
K_RESIZING 1102
K_SETFOCUS | K_FOCUSIN 1103
K_KILLFOCUS | K_FOCUSOUT 1104
K_BEGINPAINT 1105
K_ENDPAINT 1106
K_TIMER 1107
I don't agree with these. We already have
the event notification for them. I'd suggest
to define the needs and implement each
event where they are indeed needed, and
avoid triggering all sorts of parallel
events ("keypress", "event notifications",
user defined blocks and else) for these.
Also notice that some kind of masking
will be necessary, and it should be on
by default to not disturb existing code
not expecting such codes.
I'd also strongly disagree with introducing
unnecessary synonyms for existing focus event.
For a start I'd suggest RESIZE to "fire"
an event notification, instead of making
a mess out of Inkey() values.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
