I think we should have function variants which can return the whole input
event (as an array or even binary object (hb_parptrGC),
and user can select which values to use in a given situation.
This would also mean such object can be created and stuffed
into the queue by user just like we do now with bare keycodes.
Support for such values as input can be implemented inside
current functions (hb_SetLastKey() f.e.), we only need one new
variant for functions which return them.
ev := hb_evNew( nKeyCode, nRaw, nMRow, nMCol, ... )
hb_SetLastKey( ev )
KeyPut( { ev1, ev2, ..., evn } )
ev := hb_Inkey( 0 ) // or hb_evRead( 0 )
? hb_evMRowGet( ev ) // -> nMRow
? hb_evKeyGet( ev ) // -> nKey
? hb_evKeyRawGet( ev ) // -> nKeyRaw
etc... (maybe Get() is overkill, as we won't need Set() variant in practice)
For consitency, there could form a whole new Harbour Event API,
replacing current mixture of Clipper compatibility and Harbour extension
functions which aren't named very consistently anyway.
Brgds,
Viktor
On Fri, Mar 13, 2009 at 2:45 PM, Mike Evans (Gmail) <makis1...@gmail.com>wrote:
> Hi Przemek,
> I think that Clipper Ct Functions SetKXlat GetKXlat can be used. Also it
> will be nice if we have also except from the lastkey() another
> Hb_ExtLastKey() that can return the full key code.
>
> Brgds
> Mike Evans
>
> -----Original Message-----
> From: harbour-boun...@harbour-project.org [mailto:
> harbour-boun...@harbour-project.org] On Behalf Of Przemyslaw Czerpak
> Sent: Friday, March 13, 2009 3:00 PM
> To: Harbour Project Main Developer List.
> Subject: Re: [Harbour] feature request. K_CTRL_* should not overlap with
> other codes
>
> On Fri, 13 Mar 2009, Szak�ts Viktor wrote:
>
> Hi,
>
> > No. IMO, if we need to redefine Clipper compatible keycodes and do a
> local
> > build just to access these keys, the solution is
> > wrong.
> > I imagine a proper solution would look like adding a new
> > INKEY_ filter/modifier, new HB_K_CTRL_x keys with
> > alternate values, and this way the feature could be easily
> > selected at runtime. In it's current form, it's pretty much
> > unsuited for general consumption and users have to choose
> > between Clipper compatibility and this feature at build time.
> > This feature is quite important, so I hope to hear other
> > opinions on how to implement this properly in Harbour.
>
> It has to be runtime switch but IMO we should change cursor key
> values not K_CTLR_<letter> ones.
> It's a common standard that CTRL+<letter> should return
> ASC( <letter> ) - 64 on ASCII based machine. Lot of code depends
> on it.
> The other way is adding key modifiers to return values as bit field
> for CTRL, SHIFT, ALT, ALTGR flags though here I see one potential
> problem with defining portable list of basic key codes and interactions
> with national characters. So we probably should add also bits to mark
> type of keycode, f.e. ASCII character, UNICODE character, MOUSE event,
> SCANCODE.
> The mouse event should contain also the status of mouse buttons and
> mouse row/col position.
> It may be hard to keep all this information in single 32bit word
> though it's possible if we reduce maximal size of GT window for
> mouse position to 256 x 256.
> The low level GT driver should send to core GT such row untranslated
> event values. INKEY() will make translation online unless user will
> not set some INKEY_RAW or INKEY_EXT flag.
> That's all.
>
> best regards,
> Przemek
> _______________________________________________
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
> _______________________________________________
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
