Quote: You cannot tab to the top field for Database root directories, cannot tab to the filename field. cannot tab to the Accept/Cancel buttons, cannot select from the list of applications that might be showing. You can only press ESC or ALT-F4 to close the window. It is impossible to select an application from the keyboard.
Purely an oversight - did you file a bug report? It is advisible, if you are automating using a macro recorder, or Sesame's internal macro facility, or using SBasic - to launch specifying the application file (.db) on the command line. That will remove any uncertainty. Meanwhile we'll get this fixed so you can use the keyboard here.
Quote: Example 2: After the application is open, once on a record, there are many functions that cannot be done from the keyboard. There are no keyboard strokes to Exit Add/Search mode, Print, Mass Update, Export, etc. Mouse is needed again. Sometimes up/down arrow will work, sometimes a double is necessary to reestablish focus.
Not seeing this. Can you be more specific? To exit Add/Search: Escape to close to the application tree, F7 to go to search, Shift-F10 to save and close, CTRL-F6 to go to Add Mode. CTRL-UpArrow to go to the record counter (and once there, DownArrow or Tab will take you to the tree - where any command is available from the keyboard).
Print, Mass Update, Export, etc...? Are you looking for means to kick these off or to cancel them - in either case there are keystrokes for both. Though some commands are not cancelable once started. If you are talking about the spec window (bottom left corner) the advance/retreat spec buttons can reached via the keyboard using typical Arrow and Tab keys - spacebar presses the button. Each of the specs can be launched from the command tree or via shortcut keys. The Run command is on Alt-R.
I suspect that the keystroke you are missing is the CTRL-UpArrow from the form. This is the only keystroke that will leave a form that has focus. This was done intentionally to prevent a keyboard only user from accidentally leaving the form when navigating between fields using Tab or Arrow keys.
Quote: I have had some success using a macro tool that does Mouse Movements to specifi screen positions. but this will be impractical since items will be affected by screen resolutions. Using Mouse Movements with relative positioning is also working in some instances, but this will not work either. since items/objects will not always be in the same location, from alphabetization etc.
No matter what your screen resolution the buttons, menus, and other items are in the same exact position relative to the top corner of Sesame and Sesame appears on launch at the top corner of your screen - so it should make no difference at all, unless your third party macro recorder is set-up to use relative arbitrary unit (as opposed to absolute pixel based) positioning.
Quote: It is really necessary to provide the ablity to tab or use Alternative &Kkeys to get to all objects that could be mouse clicked. Even a standard key command to tab through the window frames would help.
If you could be more specific, that would help. We support not only the command structure and the majority of Q&A keystrokes, but a number of the "standard" microsoft keystrokes as well. We cannot (and should not) cycle between frames because that leaves the element within the frame that can actually receives focus ambiguous. So we force focus to the first element within the frame, where keyboarding is actually relevent. In other words, if we focus the frame (to cycle) between them, it would take a second keystroke to place the user *in* the frame on an element that accepts keyboard entry. Each frame would then have to have a "rule" set up to indicate how it determines where focus lands - rather than using the universal rule we have now.
If you are talking about moving between the "Tabs", the tree (which can always be reached via the keyboard) provides means, as well as shortcut keys, also Alt-(n) where n is the tab number (i.e.: Alt-2) will also move between tabs.
Quote: I am raising the issue primarily of the necessity to use third party macro tools (my opinion at this point), but I also don't think that operators should have to move back and forth between the keyboard and the mouse.
We agree. If you can be specific, we are fixing bugs as we receive them. With the exception of the initial file dialog, I am still unaware of any element in the Sesame runtime that cannot be reached via the keyboard. SDesigner does require the use of the mouse, but given that it is not intended for data entry, we did not see the need.
Quote: Even if Lantica feels the Sesame macro tools and programming statements will do it all, please fo not prevent me from using my own tools to simulate data entry keyboard/mouse entries. This is the only Windows application that I have been unable to use my macro tools on. I am struggling, not given up yet, but it should not be this tough to work from the keyboard alone.
Lantica (nor I) feel that either will "do it all" and we certainly encourage the use of third party tools. Once again, if you could be more specific, I will be happy to check into any particular problems you are having with any specific macro recorder. We have done nothing to prevent third party macro recorders from working. We use a standard Windows event loop and standard Windows events.
Pages: 1
Send Topic 
Print
Cannot work from keyboard alone (Read 3371 times)
