Acceleratoren in Dialogen für Felder ohne Prompt bzw. Static Control

Mit Alt+Buchstabe ein Feld in einem Dialog anspringen ist der Tastaturliebhaber gewöhnt.
Aber was mach man wenn man keinen Platz für ein Static Control hat vor dem entsprechenden Eingabefeld. Oder wenn solch ein Static gar nicht in das Design passt, oder gar eine Grafik enthalten soll.

Man könnte PreTanslateMessage überschreiben und mit Hooks Klimmzüge veranstalten. Aber es geht weitaus einfacher.

Man kann das Static Control an die korrekte Stelle in der Z-Order platzieren und dann einfach auf „Invisible“ setzen. Der Accelerator funktioniert trotzdem.
Nur Statics, die disabled sind werden als Acceleratoren ignoriert. Das Acceleratoren auch für nicht sichtbare Controls funktionieren habe ich bereits in diesem Artikel Button + Accelerator + ShowWindow(SW_HIDE) – EnableWindow(FALSE) = Falle erwähnt.

Anmerkung:
Damit ein User weiß das Acceleratoren für dieses Feld funktionieren sollte ein sichtbarer Hinweis im Handbuch existieren. Da aber wenige Menschen überhaupt Handücher verwenden :mrgreen: eignen sich hier Tooltips für den entsprechenden Hinweis.  Etwa so wie das VisualStudio macht mit Show shortcut keys in ScreenTips

In welcher Reihenfolge werden Ressourcen in unterschiedlichen Sprachen gefunden?

Immer wieder taucht die Frage auf, wie die Funktionen zum Laden von Ressourcen (LoadImage, LoadCursor, LoadMenu etc.) eigentlich arbeiten und entscheiden aus welcher LANGID-Sektion die Ressource geladen wird.

Die Dokumentation von FindResource – auf der alle diese Funktionen basieren – gibt leider keine Auskunft.

Wenn man jedoch etwas sucht wird man in der Dokumentation von Developing International Software fündig. Dort findet sich der folgende Abschnitt mit dem Titel Multiple Language Resources, in dem auch beschrieben wird wie FindResource arbeitet und wie eine Ressource gesucht wird:

If the FindResource and FindResourceEx functions do not find any resources that match the language ID’s primary language, they search for resources tagged as „language-neutral.“ This language ID is useful for resource elements such as icons or cursors that are identical for all languages. If a bitmap or an icon will differ for some languages, you can define one language-neutral bitmap as the default and specify language IDs for as many other customized bitmaps as required. For example, bidirectional applications might require bitmaps with right-to-left directionality. Because the FindResource and FindResourceEx functions always search for specific language IDs first, they will always find a bitmap tagged with that language ID before they find one tagged as language-neutral. The search algorithm they follow is summarized in the following list:

1. Primary language/sublanguage
2. Primary language
3. Language-neutral
4. English (skipped if primary language is English)
5. Any

Der # operator im RC-Compiler arbeitet inkonsistent

Heute ist mir ein übler Fehler des Ressourcen Compilers untergekommen.

Beabsichtigt war es einen #define in einen Text umzuwandeln, der als Ressourcen-String abgelegt wird.

Das ganze wurde so implementiert:

#define _MYSTRING(x)   #x
#define MYSTRING(x)    _MYSTRING(x)
STRINGTABLE
BEGIN
4713 MYSTRING(0409)
4714 MYSTRING(040E)
END

Alles kein Geheimnis, nur macht der Ressource-Compiler was er will. Der erste String wird korrekt angelegt. Beim zweiten wird wie durch Zauberhand noch eine 0 angehängt.

Das ganze Problem konnte ich auf allen VS-Systemen (VS2003, VS2003SP1, VS2005 und VS2005 SP1) nachvollziehen.

Gemeldet für Microsoff-Feedback unter:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=252616