Is there a way to make a command button activate ONLY if it clicked with the mouse (as opposed to using the "Enter" key to navigate around the form?)

I suppose I could do that, but it will break up the visual rhythm of my form (I have "delete line" buttons at the end of each line of related elements).  My cow-orkers, used to using the Enter key to navigate around Q&A, will slam into these each time they pass through the line of elements, deleting all the entries they just made.  I'd like to make the buttons click-only, if possible.

I could also use Throwfocus but I've tried to avoid that as much as possible, as per Erika's training.

Thanks Mark, Navigation Order is something I haven't looked at before.  Looks very useful.

Why arrows, in particular?  I've strenuously taught my users not to use their arrows in Q&A (as then can then jump fields that contain programming) but to use Tab and Enter instead.  I have no problem teaching them new techniques, but old habits will be hard to break.  But anyway, are Up and Down better to use than Tab and Shift-Tab?  If so, why?

Thanks again!

The cursor keys, the page up, and page down keys, in particular were created for navigation. They have no other meaning, and their meaning is reasonably clear. Tab, on the other hand, has a dual meaning. It can mean insert the tab character here (ASCII 9), or it can mean navigate to the next field.

As such, it is inconsistent by its own definition. In a sense, it is a "stolen" key forced into navigational servitude.

Enter is not much better, whether labeled "Return" - meaning the navigational "return to start of line, on next line", or "Enter" which generally means "Enter the data, leaving the field or the form or the line or the ...".

Because of ambiguities like these, different GUIs do different things, when confronted with unclear keystrokes. Sesame's GUI library, prefers the clearer message of up/down/right/left. Unaltered, it would actually send the focus directionally. Unfortunately, some felt that the non-linear navigation, while extremely efficient and intuitive, would be unfamiliar to users not used to having the cursor go in the direction they point with arrow keys. So I altered it so the up and shift-tab do the same thing. Down and Tab are mildly different. Tab will, for example, navigate out of a multiline element, whereas down will navigate through it. In any case, this causes a semi-linear navigation model.

The reason Enter selects, is because some felt that the "spacebar" means of selection was obscure and that leaving it at that would cause people to "have to reach for their mouse".

My wife, who's expectations are less jaded by other programs, thought the Enter key should "Enter" (read "submit") the entire form, like it does on HTML forms using most browsers. Of course my wife once asked what the "F" as in "F10" stood for. I told her it stood for "Function" as in "Function Keys". She scowled and said, "I thought it stood for something else!"

That is, of course, a very common reaction when we show Sesame to non-Q&Aers.

I'm not sure how the navigational rules got set in Q&A. There are some peculiarities going forward versus going backwards versus using tab versus enter versus the arrow keys versus using the mouse. Never, in a GUI, count on the user visiting or not visiting any particular elements. Like a hard drive is more efficient than a tape drive, because it provides non-linear ("random") access to any point on the harddrive with having to touch all the points between current position and target position, a GUI provides non-linear access to the form.

Infinity,
You might try a different approach. Use more than one layer of buttons, where the first button causes the rest to be accessible, but is otherwise harmless.

Build a form similar to this one, where you have a box with your buttons on it at the very bottom of the form:


Now, put a button at the top of the form and label it appropriately. I used "Open Command Buttons" as my label. Set the new box, and the buttons on the box to be invisible.

Now put code similar to this in the On Form Open event:

Visibility(LE4, 0) // the box
Visibility(One, 0) // My three buttons
Visibility(Two, 0)
Visibility(Three, 0)
Visibility(Close, 0)

YPos(LE4, 200)
YPos(One, 220)
YPos(Two, 220)
YPos(Three, 220)
YPos(Close, 260)

ForceRedraw()
 

Now put code like this in the "Open" Button's On Entry event

Visibility(LE4, 1)
Visibility(One, 1)
Visibility(Two, 1)
Visibility(Three, 1)
Visibility(Close, 1)
ForceRedraw()
 

And code like this in the On Enter event for the "Close" Buttons

Visibility(LE4, 0)
Visibility(One, 0)
Visibility(Two, 0)
Visibility(Three, 0)
Visibility(Close, 0)
ForceRedraw()
 

When the open button is pressed, your panel of buttons should appear


When the close button is pressed, it will go away and cannot be navigated to because all of the buttons are invisible. Basically a popup button bar.

I don't know about the rest of the team, but I think its a pretty good idea.

Sesame 2.0 has:

On Form Delete
On Form Delete
On Reveal
On Hide
On Form Reveal
On Form Hide
On Draw
Universal Event

in addition to the events in 1.x.x. It also has a few event sttribute commands and functions for determining things like which mouse button was pressed and etc...

Many more events are likely to make the code hard to follow and somewhat fractured.

PS:
Infinity, if you got here by skipping earlier posts, go back and read Bob Scott's post. His idea works well for people navigating with Enter.

Infinity, if you got here by skipping earlier posts, go back and read Bob Scott's post. His idea works well for people navigating with Enter.