6 Replies Latest reply on Jul 11, 2014 9:01 AM by flukey

    Show Custom Dialog / Capture Keystroke

    deninger

      Consider the following:

       

      Let's say I put up a custom dialog with two or three button choices (and no input fields). I can use Get (LastMessageChoice) to capture the button pressed and direct my script to handle the situation from there.

       

      Some of my users don't like having to go to the mouse (they are keyboard snobs, if you like) and want to simply use a hot key to trigger the option they want to select (e.g. type 'n' to 'press' the New button, 'r' to 'press' the Refill button or 'd' to 'press' the Discontinue button).

       

      I would love to find a way to capture keystrokes while Show Custom Dialog is running and be able to use this input to close the dialog and move on within a single script.

       

      So I started thinking about using a Modal Window and script triggers with Get (TriggerKeystroke). As I consider it, though, I can visualize just two methods to proceed. Either:

       

      1) I have to pause the script at the dialog step to wait for input either from the keyboard or the mouse. During this pause:

      a) The keyboard input would trigger a second script to handle the keystroke and then I have to somehow return the result to the currently paused script. I can only think of 1 way to do this; global variables (and I try to avoid these!)

      b) Pressing a button with the mouse could either set a local variable OR resume the script, but not both. So I would have to call another script for each button press instead (and then return the result to the paused script with the same limitations above)

      c) With either user outcome, I have to resume the paused script after the user input (how!)

       

      or

       

      2) Stop one script and let the keystroke or mouse input start a new script to pick up where the last one left off. This has its own set of consequences:

      a) The logic is split up and more difficult to follow

      b) you have to do this EVERY time you bring up a dialog box in this fashion, so a script may have to be divied MANY times into constituent parts

      c) having two or more break points in your logic (where dialogs are opened) creates the possibility of unforseen situations (bad programming, clever users doing things in an unanticipated way etc) that can possibly leave the data in limbo and not finished)

       

      Any thoughts, insights or work-arounds would be most welcome.

        • 1. Re: Show Custom Dialog / Capture Keystroke
          PeterWindle

          Thinking 'outside the box', what if you have custom menus with keyboard shortcuts that are specific to that layout only?

          • 2. Re: Show Custom Dialog / Capture Keystroke
            user19752

            What version / platform do you need to work ?

            I guess you want OSX solution since it is very easy for Windows

            (add &c text on label to make shortcut 'c') and easily traverse on buttons with tab key.

            • 3. Re: Show Custom Dialog / Capture Keystroke
              deninger

              Thanks for the replies. Both are things I have considered. The custom menu has the same issues as using Script Triggers to capture the keystrokes. And on MacOS, one can use the accessibility preferences to allow one to tab between dialog buttons (similar to the Windows trick above). Making global changes on a macine for a single app is a little extreme, though.

               

              I guess that I am a little flummoxed by this as there has to be a better way. When the modal window type was introduced, I THOUGH that this was exactly the sort of thing it was created for, but now that I am trying to use it in this way, I see that it is not so simple.

              • 4. Re: Show Custom Dialog / Capture Keystroke
                Stephen Huston

                deninger wrote, in part:

                 

                     b) Pressing a button with the mouse could either set a local variable OR resume the script, but not both. So I would have to call another script for each button press instead (and then return the result to the paused script with the same limitations above)

                     c) With either user outcome, I have to resume the paused script after the user input (how!)

                In a Button Setup, the option allow the button to perform a script step or a script, either of which can set a $$variable (which can be read by the resumed script), and you can set the button to Pause, Halt, or Resume any paused script.

                 

                You can also clear that $$variable at the end of the resumed script, if you don't like leaving $$variable values floating around, by using another Set Variable step to set it ="".

                • 5. Re: Show Custom Dialog / Capture Keystroke
                  DavidJondreau

                  You could make it all one script, with a variable to determine where in the script to start. Even a counter to track progress...

                   

                  Set Variable [ $$counter ; $$counter + 1 ]

                   

                  If[ $$counter = 1]

                  New Window [ Modal ]

                  Go to layout

                  Show Custom Dialog

                   

                  Else If [$$counter = 2]

                  Show Custom Dialog

                   

                  Else If [ $$counter = 3 ]

                  Do Some Stuff

                  Close Window

                  End If

                  • 6. Re: Show Custom Dialog / Capture Keystroke
                    flukey

                    If you are using FM13 try using a popover.  You can create  popover button, permanently hide it, and trigger the popover when needed.  You can set the layout to trap keystrokes at that point so that you can respond as needed.  You will need to trap the popover close trigger so that it will only close when your particular conditions are met, thus simulating a modal window.  You may also want to trap the record commit to ensure that the user cannot inadvertently change records on you.

                     

                    The painful part is that you will need to do this on every layout you need this function, as well as you may have to split the logic to launch it and process and close it into a couple of scripts like you mentioned in your post.  A pain, but doable.  I used this in a project and it worked fine. I created a generic script to launch, trap the trigger and process the keystroke, that I was able to reuse in several layouts just by passing the approriate parameters.

                     

                    Flukey