The subject of using ampersands in the text of statics (text controls) is missing from the documentation. Or I should rather say subjects - in plural.

The first issue is how to get an ampersand to display in the text of a static. An ampersand by itself causes the next character to be underlined, just as in the text of a button, menu, or menu item. The trick is to use two ampersands in a row: "Max&Moritz" will display as "MaxMoritz". "Max&&Moritz" will display as "Max&Moritz".

If you set the text of a static programmatically, and that text might contain "any" character (might e.g happen if the origin of the text is user data), you really should swap all "&" with "&&" in the text first.

The second issue is how to put the underlining to good use. Underlined characters in the text of buttons, menus, and menu items are for accelerator keys, and I believe that also must be the purpose of underlined characters in statics.

An underlined character "x" in a static's text causes Alt+X to become an accelerator key, which I think will try to set focus to the static. Since a static can't have focus, the focus goes to the next control in tab order. This can be useful for edit controls with prompts. Let the text in the prompt have an accelerator, make sure that the edit control follows the prompt static in tab order, and the user can set focus to the edit control from the keyboard by using the accelerator instead of the mouse. (I use that in my version of the FINDINFILES window, for the Find what prompt.)

Note that such accelerators only work when the text is set at design time. If it is set programmatically, the underline will still show, but nothing will happen when the user hits the accelerator. There might be programmatic solutions for this possible problem. If it can't be fixed directly I think one could work around by having a collaborating (and perhaps hidden) menu item with the same accelerator.

- Oystein -

Thanks Oystein

Oystein,

Thanks. Both are great tips. I will include them in the next version of the documentation.

Ira

[email protected]

Jim,

I thought of you when I wrote that posting.

But I don't think we have an explanation for Mark's original Mysterious Flying Cursor. Do you?

- Oystein -

Jim,

I thought of you when I wrote that posting.

But I don't think we have an explanation for Mark's original Mysterious Flying Cursor. Do you?

- Oystein -

Sorry for posting twice.

And I posted too soon!

Because right after I did I saw the Real Original Mysterious Spacebar-Induced Flying Cursor!!

And so can you all!!!

Make a new form.

Add an edit line.

Add a static with a text "Tom & Jerry". Be sure to put a space after the ampersand.

Add another edit line.

Save and compile.

Test run.

With focus in the first edit line hit the Space bar and watch the caret fly to the second edit line.

- Oystein -

Good call!

The Sprezzatura Group

World Leaders in all things RevSoft

What next? Revelation fix it or Ira document it?

- Oystein -

We'd go for document it - it is expected behaviour when all's said and done. Though a Window precompile message might be nice

The Sprezzatura Group

World Leaders in all things RevSoft

Sprezzatura,

Expected behaviour????? Please explain. What exactly is it that happens when the user presses the Space key?

- Oystein -

Add a static with a text "Tom & Jerry"

I assume that by "static" you mean a fixed label. Problem is, there is nothing on my form with an "&" - unless it's hidden somewhere and I can't see it. I turned on "show hidden controls", and I don't see anything. Is there any other way I can check for a hidden "&" sign?

[email protected]

BG-Map Botanical Garden Mapping System [img]http://www.bg-map.com/bgmap.gif[/img]

Mark,

Yes, with static I mean text control - the kind of control which often are used for labels/prompts.

If that ampersand is in some text of a window, you should be able to locate it by opening the SYSREPOSWINS row of the window in System Editor and do a Find (Ctrl+F or Shift+F3).

…unless the text with the ampersand is set programmatically, in which case I believe the mystery wouldn't happen, if it's got something to do with accelerators.

- Oystein -

Mark,

Perhaps the ampersand is in a menu. But searching the SYSREPOSWINS row should find that too.

- Oystein -

Oystein,

Thanks so much for your suggestions. I searched SYSREPOSWIN for "&" and found none. The flying cursor is even more mysterious than I previously thought. This table has a 4-part key. Part 1 is "Class" - 2-characters. Part 2 ia "Type" 3-characters. Part 3 is "Item" 3-characters, and part 4 is "Number" - a sequential integer key.

The flying cursor only happens for certain Classes and Types, as described below by the client:

I've observed that the cursor only moves in certain classes - Enclosures (EN) snd Transportation (TR). Could those letters together as a class have something to do w/ the the problem? (The other classes are Buildings (BU), Living Resources (LR), Utilities (UT)) Under Enclosures most of the types (Agriculture, Residential, etc) and items (Fences) have been used elsewhere (say under Buildings - BU-AGR-etc) with no problems, so I don't think a problem lies in the types or items here. The types under Transportation (Water, WAT and Land, LAN)and items (Hitching Post HPO; Bridge BRI; Paths, Lanes Street PLS; Traffic Sign TSG; Residential Sign RSN) have not been used under other classes, so maybe there could be a problem here.

[email protected]

BG-Map Botanical Garden Mapping System [img]http://www.bg-map.com/bgmap.gif[/img]

Mark,

I find no clues to the mystery in what you describe here.

But neither do I know what causes "my" cursor (caret) to fly. I'm really curious about what Sprezzatura are going to tell me.

- Oystein -

Don't hold your breath - it was simply Windows becoming confused and not needing an alt for the space (Alt-Space being reserved and all…)

The Sprezzatura Group

World Leaders in all things RevSoft

Sprezzatura,

Windows becoming confused all by itself? Would the same thing happen with forms made with other tools than OI?

I can't see what Alt+Space being reserved has to do with the problem. Of course if the user pressed Alt+Space there might be confusion about what should happen - system menu or static focus.

Now get out and explain properly and don't be so stingy with details!

- Oystein -

Oystein,

While you're reading this message (assuming you're using IE) try pressing Alt+Space and see what happens…

Tim

Tim,

Sure. I'm a keyboard guy. I know what happens. I use Alt+Space X all the time to max Word and other MS app windows.

But what has that got to do with the MFC?

- Oystein -

Oystein,

If you change the tab order so that the static text doesn't follow the first editline ie Editline_1 is tab 1, Editline_2 is tab 2 and Text_1 is tab 3 this phenomenon doesn't happen…

After trial and error it appears to only happen if the text label is in between the editlines in the tab order. Putting the text label last in the tab order stops it happening completely. When you think about it this is sort of what you would expect. Text labels by definition can't have focus, so by trying to out focus on it by assigning an accelerator key you would expect focus to go to the next control. The only bit missing appears to be why you don't need to press the Alt key!!! Having said that, if you press the Alt key in any WIndows app the menu options are active and any key press then gets trapped for the accelerator key value. (What a load of waffle that was!!!)

Tim

Tim,

Thanks for the details about tab order.

The only bit missing appears to be why you don't need to press the Alt key!!!

Yes!

Now it's like you press Space, and the dopey system says to itself "Oh, the user pressed Space, hmmm…, now what if he'd done Alt+Space, that would have been an accelerator for the system menu, but that's not what he meant, he didn't mean the system menu, he meant that other thing,…", and at this point the system totally forgets it's completely normal to press Space and really mean a literal Space, "…he meant that other accelerator Alt+Space I found in that funny static, yeah!"…

- Oystein -

Oystein,

I wonder if it's actually too clever and realises that the text label can't get focus so traps what it would do if it did have focus, a bit like it does when a menu is selected by pressing Alt on it's own.

Maybe I'll try trapping the keystokes and check what the control key values are. They might be different if the tab order is different.

Tim

Tim,

I wonder if it's actually too clever and realises that the text label can't get focus so traps what it would do if it did have focus, a bit like it does when a menu is selected by pressing Alt on it's own.

Sort of makes sense.

My description of what happens wasn't meant to make much sense.

Maybe I'll try trapping the keystokes and check what the control key values are. They might be different if the tab order is different.

Neat.

Here are some additional observations I did today. They might not be new to you:

(1)

I tried with a form containing more than one edit line before the text control:

EDITLINE_1

EDITLINE_2

TEXT_1

EDITLINE_3

I got the MFC effect in both EDITLINE_1 and EDITLINE_2. In both cases the cursor flew to EDITLINE_3. So the edit line doesn't have to be directly before the text control.

(2)

The Space you press get entered into the edit line before the cursor flies. So the Space is used twice, so to say.

- Oystein -

Oy,

Maybe it's something to do with the space-time continuum, I'm off to buy a De Lorean…

Tim

View this thread on the forum...