Re: [Oorexx-devel] Input on [ 1779444 ] Enhance ooDialog for function key or hotkeys

[Rick M. <obj...@gm...>]

On 10/2/07, Mark Miesfeld <mie...@gm...> wrote:
>
> A number of people have expressed interest in being able to detect
> function key, or ctrl-key, or alt-key, etc., key presses in ooDialog.
>
> I have this implemented and want to commit it before the 7th so it
> will be in 3.2.0.   I'd like any one's input on this, so that Chip
> can't accuse me of arbitrarily making changes without discussion.
> <big grin>
>
> * You will be able to connect any key press with a method in you
> class.  There will be a (group) of methods that are members of the
> base dialog class.  And another group of methods that are members of
> the base dialog control class.
>
> a.) Using the dialog class method(s) will connect your event to any
> key press when the dialog is the active window.  It will not matter
> what control has the focus.
>
> b.) Using the dialog control method(s) will connect your event to any
> key press only when the associated dialog control has the focus.
>
> * You can set up a range of keys to invoke a single method.
>
> * You can set up a filter so that only the key presses you specify
> invoke your method.
>
> * You can set up a number of different method invocations.
>
> The above means that you could, for instance, set things up so that a
> key press of F7 invoked one method in you dialog, Alt-c a different
> method, and Ctrl-F2 through Ctrl-F12 invoked a 3rd method.
>
> Here is what is still up in the air.  I can of course do what I think
> is right, but if anyone has any opinions here, the following is
> flexible.
>
> 1.) The name for the method(s)
>
> The underlying method to capture key presses sent when the dialog is
> the active window and the the method to capture key presses sent to a
> dialog control are completely different.
>
> So I started out with a different method name for the dialog class
> method and the dialog control method.  But, the user does not need to
> know the underlying implementation is different, so it makes sense to
> me to have only 1 name.
>
> I currently have:
>
> dialog~connectKBHook
>
> and
>
> dialogControl~connectKeyPress
>
> I am thinking both methods should be connectKeyPress.


I think I'm in favor of that too.



2.)  In other connectXXX methods in ooDialog, because of the
> implementation, you can only have 1 method connected to any event.  In
> the implementation for key presses you can set up a number of
> different method invocations for the same event (a key press.)
> Because of this I currently have one method to set up the hook the
> first time and then another method to add methods once the hook is in
> place.  E.g.:
>
> dialog~connectKBHook(msgToRise, keys, filter)
>
> and
>
> dialog~addToKBHook(msgToRise, keys, filter)
>
> But, there is no reason I can't change that to just one method for
> both scenarios.  E.g.:
>
> dialog~connectKeyPress(msgToRise, keys, filter)
>   if hook not installed then install hook with msgToRise
>   else add msgToRise to already installed hook
>
> I guess only having one method is simplier.


Simpler, and you might have the case where a class is a subclass of
another.  The superclass might already have used the connect method, forcing
you to use add.  How do you know?  And you set up a fragile baseclass
situation if the superclass ever changes to not use the connect, now the add
is invalid.  One method will make this generally easier to use.

btw, how do you remove the connection if circumstances change such you're no
longer interested in the events?



---
>
> Here is the current syntax:
>
> connectKBHook(msgToRise, keys, filter)
>
> msgToRise:  the name of the method to be invoked in your class
>
> key:  A string specifying which key presses to look for.  The format
> for this is the virtual key number [or range of numbers], separated by
> commas.  I also have a few keywords that specify some predefined key
> ranges.  It would look like the following:
>
> keys = "118, 120, 113-116"
>
> spaces don't matter so you can format the string however pleases you
>
> keys = "118,120,113-116"
> keys = "118   , 120,113  -     116"
>
> are all the same.  I also, so far have the keywords  FKEYS for all
> function keys.  ALL for all keys.  And some form of ALTALPHA which
> would mean all alt-A through alt-Z and ctrl-A through ctrl-Z (so the
> name is not too good.)
>
> filter:  a filter to apply to the keys.  The filter is optional.  It
> consists of any the following keywords AND SHIFT CONTROL ALT, case is
> not significant.  If you have AND, the filter is an and filter, if not
> the filter is an or filter.  The filter specifies what other keys need
> to be down to invoke you event.  For example with the above keys, if
> you had this filter:
>
> "and alt"
>
> Your method would only get invoked for: Alt-F2 through Alt-F5, Alt-F7,
> and Alt-F9.  Things like Ctrl-Alt-F2 would not invoke your method.
>
> * The method that gets invoked gets 4 arguments and could look like this:
>
> dialog~connectKeyPress(onF7_F9, 118-120)
>
> ::method onF7_F9
>   use arg key, shift, control, alt
>
> key: the numeric value of the virtual key.
> shift, control, alt are all boolean.  If true the respective key was
> down at the time of the key press, if false it was not.
>
> * You can use any of the virtual keys defined by Microsoft.
>
> You can of course use the VirtualKeyCodes class to get your key
> numbers.  That is a subject for another e-mail.
>
> --
> Mark Miesfeld
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Oorexx-devel mailing list
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>