User defined keystrokes can be a problem in two regards:

1. In GUI programs events are not handled by a central module, they are instead, passed to windows, each of which responds to, or chooses not to respond to an individual event. That means that any particular keystroke can have, or fail to have, meaning to any particular window. So the SBasic programmer, setting up these keystrokes would have to be extremely context aware, and the duration of that keystroke's "meaningfulness" would have to be limited to the duration of the context that set it. In other words - what does your keystroke do if there is no record to save, or if there are nine records to save (open in nine forms, but the user is on the application menu)? Everyting in a GUI program, is about context. Context is both a set of modes (unfortunately) and temporal. This is why, in all programs, macros need to have known starting points. This is why, in Q&A, keystrokes that are not appropriate to the current menu or dialog, do nothing. Should we allow the programmer to alter an existing keystroke, we would also have to tell each of the contextual components that react to that keystroke, not to react - thus causing them to no longer function, unless the programmer also supplies a replacement keystroke in each and every context.

2. Having a different set of commands/keystrokes for each and every application that is deployed means that no one can ever gain runtime expertise in the package. The learning curve for commands must be relearned with every installation of each and every application. Even on the same desktop, two different applications of Sesame may (and likely) will behave and react entirely differently, based on which programmer created it. Additionally, it becomes impossible for a third party (like Lantica) to support the application, in that the users can only learn the package based on the narrowed set of commands as defined by their programmer, who may well have moved to Japan in the interval.

On the other hand:
I would like to add to Sesame, the ability for the programmer to launch code based on hotkeys or menu events. It would have to be limited to keystrokes not already assigned in that context, and the code would have to be context sensitive. There have long been plans to add user defined pulldown menus to the menubar. These items would be set to run either a macro or a chunk of SBasic. The problem is still context. The programmer would have to have some way to tell Sesame which form under which mode, each menu or menitem appears or is active. Unassigned hotkeys could then be assigned to the menu and its items and only become "hot" when the system is in the appropriate mode and context.

Normally in both Q&A and in Sesame, you would do what you describe using an XLookup program, not a macro.

In most cases, you can replace what you used to do with macros by using SBasic.

I'm not sure you understand the situation.  The way the QA database works is you type a macro keystroke such as "Alt-a" and the macro types the predefined text in the field. The next field looks up the text entered by the macro and retrieves information for two subsequent fields.  This has saved countless keystrokes over the years in QA.  The data entry clerk is so used to the macros that eliminating them would be hard to adjust to.  You mean, I've been doing this the wrong way for 15 years?  The macros worked really well for 15 years, even if they were the wrong way of doing it.

Quote:


I didn't mean to imply that you (or Q&A) were doing anything "the wrong way". I was trying to post a set of approaches you could use to implement automation (in general).

Given, how you are using macros, I would be tempted to replace them with a combo-box. That way the user can select an item off of a list, and they do not have to memorize which keystokes go with which values. And, after they have learned what values are available, simply typing the first letter of the option will automatically select it. Addtionally, using PopulateListElement, a set of combo-box values can can set dynamically. If the LE is only allowed to have a particular set of values, a List Box LE disallows any typing - and thereby disallows any "creative" responses.

Of course, in terms of time savings, if the element must be a text box (though I don't know why that would be), Ctrl-Enter will provide a list of the last 10 values typed into that text box.

If none of these approaches are flexible enough: the On Immediate Change event will allow you to enter a keystroke into the LE, catch that keystroke and replace it with any of a set of pre-defined values that "match" that keystroke.