Rätselhafte Auswahl bei Microsoft…

Immer wieder staune ich über die rätselhafte Auswahl von Funktionen, die es als Wrapper in die MFC geschafft haben. Warum werden nicht alle Funktionen in die MFC Wrapper aufgenommen?

CImageList::GetIconSize sucht man vergeblich, man muss die API Funktion ImageList_GetIconSize verwenden… OK, wenn diese Funktion nicht in allen Windows Versionen verfügbar wäre. Aber gerade diese Funktion existiert schon seit der aller ersten COMCTL32 Version!

Man könnte meinen, dass mit der Zeit fehlende Funktionen irgendwann mal in neueren Funktionen nachgerüstet werden, aber da hofft man scheinbar vergebens.
Immer wieder verwirrt mich das. 😕

Kann man GDI Objekte aus anderen Prozessen verwenden und auslesen?

Frage eines Regulars neulich in microsoft.public.de.vc

Habe einen HRGN Handle von einem anderen Process.
Deshalb liefert GetRegionData wahrscheinlich Size 0 zurück.
int iSize = ::GetRegionData((HRGN)hHandle, 0, NULL); 
Wie kann ich GetRegionData eines anderen Processes auslesen ?

Die Antwort ist klar und eindeutig ein Nein!

Zitat Feng Yuan in einem fast 7 Jahre alten Thread, den ich mir damals hinter die Löffel geschrieben habe:

On Windows NT/2000/XP, GDI does have a system-wide GDI object table. But certain data is stored in per-process user mode area, and the process ID of the creating process is stored in GDI object table.
For every operation with a GDI object, GDI32.DLL always checks for matching  process ID. So cross-process usage of GDI object is not allowed by design, at least for NT/2000/XP.

Wem das aber nicht langt, der kann diese Info auch in der MSDN nachlesen unter GDI Objects (gleich der erste Satz):

GDI objects support only one handle per object. Handles to GDI objects are private to a process. That is, only the process that created the GDI object can use the object handle.

Wer also Informationen zu GDI Objekten aus anderen Prozessen benötigt, der muss wohl oder übel zu DLL-Injection greifen.

Die Unsitte GetAsyncKeyState statt GeyKeyState zu verwenden…

Immer wieder wird in Foren gefragt, wie man  feststellen kann, ob z.B. die Umschalt- oder Strg-Taste gedrückt ist.
Nur zu oft liest man als Antwort: Nimm GetAsyncKeyState ❗

Zwei Dinge stören mich an dieser Antwort:

  1. Dem Frager ist meistens gar nicht bewusst, dass es für die entsprechenden Tasteneingaben immer auch eine entsprechende Nachricht WM_KEY… Nachricht gibt.
    Hier wäre ein Grundstudium der Windows API angesagt!
  2. Ist den meisten Fragern (und Antwortenden) nicht klar, das Nachrichten chronologisch einlaufen aber GetAsyncKeyState den aktuellen Zustand der Taste zurückgibt, eben asynchron, wie der Name es schon andeutet.

In den meisten Fällen ist diese Antwort also falsch!

Im Detail will ich das auch erklären:
GetAsyncKeyState liefert den Zustand der Umschalt-Taste zu dem Zeitpunkt an dem die Funktion aufgerufen wird. Im Gegensatz dazu liefert GetKeyState den Zustand der Taste zu der Zeit, als die Nachricht die aktuell bearbeitet wird einlief, bzw. erzeugt wurde. (Genau genommen geht es hier um die letzte Windows-Nachricht)
Das Problem wird offensichtlich, wenn das OS durch hohe Prozessorauslastung Nachrichten etwas verzögert abarbeitet. Es ist klar, dass GetAsyncKeyState zu falschen Ergebnissen führen muss, bzw. ein evtl. gedrückte Strg-Taste evtl. nicht beachtet wird. Die Folge könnte sein, dass aus einer Kopieraktion, ein Verschieben wird. Fatal für den Benutzer.

Eigentlich fällt mir gar kein vernünftiger Grund ein GetAsyncKeyState zu verwenden! Außer man pollt, und pollen ist das Letzte was ich in eine Windows Applikation machen wollte.

Vermutlich hat irgendwann irgendein etwas unterbemittelter Programmierer angefangen einen Tipp mit GetAsyncKeyState zu geben und dieser Unsinn kursiert nun auf ewig durch die Netze…

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

CB_ADDSTRING/CB_INSERTSTRING+CBS_UPPERCASE+Unicode+const String Pointer == das große Erstaunen

Es gibt immer wieder Momente in denen einen die Win32 API in größtes Erstaunen versetzt.
Meistens ist dies allerdings in diesen Momenten nichts positives. Das zweite Erstaunen folgt, dann wenn man in der MSDN nachliest und das Verhalten  als dokumentiert vorfindet. Meistens endet solch eine Kette dann in einem Kopfschütteln und dem Gedanken: Das darf doch gar nicht sein.

Genug der langen Vorworte:

  • Gegeben ein normales MFC Projekt. (WinAPI pur tut es auch 😉 )
  • Ein Dialog
  • Darin eine Combobox als Dropdown mit Eingabemöglichkeit
  • Die Combobox wird mit einigen Variablen Werten gefüllt mit CComboBox::Addstring/InsertString, was letzten Endes nur ein Wrapper für CB_ADDSTRING/CB_INSERTSTRING ist.
  • Das ganze sieht also in OnInitDialog in etwa wie folgt aus
cb.AddString(CString(MAKEINTRESOURCE(IDS_DATA1)));
cb.AddString(CString(MAKEINTRESOURCE(IDS_DATA2)));
cb.AddString(CString(MAKEINTRESOURCE(IDS_DATA3)));
cb.AddString(strSomeDynamicData);
cb.InsertString(0,_T(""));

Alles OK… Als letztes noch den Stil CBS_UPPERCASE dazu – weil hier eben nur Eingaben in Großbuchstaben erlaubt sein sollen und Sinn machen – und… Peng!
Das Programm schmiert ab. 😮

Was ged’n hier ab Alder ❓

In den tiefen des Aufrufs von cb.InsertString(0,_T(„“)); schmiert mein Programm ab. UAE
Nun aber doch großes Erstaunen, denn der selbe Code funktioniert in einem MBCS Programm.
Es liegt eindeutig an der Nutzung von CBS_UPPERCASE und Unicode.

Jetzt habe ich schon gedacht einen Bug in Vista und XP gefunden zu haben, denn auf beiden schmiert bersagter Code ab. Und wahrscheinlich ist es auch ein Bug! Aber das genauere Nachlesen der MSDN belehrt mich eines besseren. Dieses dämliche Verhalten ist dokumentiert, zumindest für CB_ADDSTRING (der Zusatz fehlt in der CB_INSERTSTRING Doku):

Comclt32.dll version 5.0 or later: If CBS_LOWERCASE or CBS_UPPERCASE is set, the Unicode version of CB_ADDSTRING alters the string. If using read-only global memory, this causes the application to fail. ❗

Unfassbar! Die Nachricht ist dabei selbst so beschrieben, wie es sich jeder vernünftige Entwickler auch denkt und vor allem erwartet, eben mit einem LPCTSTR:

lResult = SendMessage(      // returns LRESULT in lResult
     (HWND) hWndControl,    // handle to destination control
     (UINT) CB_ADDSTRING,  // message ID
     (WPARAM) wParam,      // = 0; not used, must be zero
     (LPARAM) lParam       // = (LPARAM) (LPCTSTR) lParam;
);

Aber was nützt schon ein vernünftiger Gedanke eines Entwicklers wenn es um das irrwitzige Eigenleben der Win32 API geht.
Und denke nie einen Bug gefunden zu haben, bevor Du nicht jede Zeile der MSDN studiert hast 😉

Vista Stil bei Tree-Controls und List-Controls

Unter Vista wurden die Tree- und List-Controls noch einmal kräftig aufgemöbelt.
Diesen neuen Look kann man auch in seinen Applikationen nutzen und das mit 2 simplen Codezeilen.

#pragma comment(lib,"uxtheme.lib") 
SetWindowTheme(m_myCtrl.GetSafeHwnd(),L"Explorer",NULL);

Und schon hat man die neue Darstellung des Tree-Controls mit den Dreiecken, die Knotenlinien sind weg.
Beim List-Control hat man nun die hellblaue Färbung mit dem Hover-Effekt.

Vorraussetzung dafür ist, dass auch ein Manifest für die Windows Common Controls Version 6 vorliegt. Dem entsprechend ist SetWindowTheme und die Uxtheme.dll erst ab Windows XP verfügbar. Wer das ganze auch kompatibel mit Windows 2000 haben möchte, der verwendet natürlich das dynamische Laden der Uxtheme.dll und sucht den Einsprungpunkt für SetWindowTheme mit GetProcAddress!

Siehe auch MSDN Doku zu SetWindowTheme

Arithmetik mit GetTickCount

Immer wieder sehe ich Code um GetTickCount oder Aussagen, die sich um den Überlauf von GetTickCount drehen, der alle 49,7 Tage entsteht. Muss man also irgendwelche Vorkehrungen treffen, wenn man Zeitdifferenzen errechnen will?

Eigentlich muss man sich gar nicht darum kümmern, sofern man in 49,7 Tagen eben mindestens einmal diese Differenz errechnet und das damit dafür gesorgt ist, dass diese Differenz nicht größer sein kann als eben besagt 49,7 Tage.

DWORD dwStart=::GetTickCount(); 
while (::GetTickCount()-dwStart < dwTimeout) 
   DoSomething();

Die Arithmetik über unsigned Integer macht es an dieser Stelle möglich. Dieser Code funktioniert, solange eben DoSomething nicht länger als 49,7 Tage dauert. Das ist die einzige Bedingung!

Leider schweigt sich die normale Windows SDK Doku zu GetTickCount darüber aus.
http://msdn2.microsoft.com/en-us/library/ms724408.aspx

Eigentlich problematisch an dieser Stelle, ist es nicht Differenzen zu bilden sondern Vergleiche durchzuführen ❗

Einen interessanten Zusatz dazu findet sich jedoch in der Windows CE Doku. Warum dieser Zusatz nicht auch in der normalen SDK Doku steht ist eigentümlich. Im Allgemeinen empfinde ich die CE-Doku in der MSDN immer eher als lästig.
Es ist aber eben wahrscheinlicher, dass dein CE Rechner und dementsprechend Programme die darauf laufen, länger als 49,7 Tage laufen als auf einem Desktop, ohne einen Reboot, alleine schon wegen der Security Updates, so kann man sich diesen Umstand zumindest erklären.
http://msdn2.microsoft.com/en-us/library/ms885645.aspx

When using GetTickCount, subtraction is safe but comparisons such as

if (GetTickCount() > MyTickCount)

are not. You can use the GetTickCount function to time the duration of an activity as shown in the example below, but using GetTickCount for any other operation will cause issues.

wOldTime = GetTickCount(); 
DoSomething(); 
dwTimeElapsed = GetTickCount() – dwOldTime;

Gleiches findet sich in der Windows Mobile 6 Doku noch etwas besser
http://msdn2.microsoft.com/en-us/library/aa915056.aspx

When using GetTickCount, subtraction is safe, even if the rollover occurred, and subtraction always yields the correct difference and the number of clock ticks passed between two tick values. Comparing tick values directly does not always yield the correct results; only compare the differences. Be sure that your code can service the difference before the second rollover, that is, before another 49.7 days pass. Comparisons such as the following are not safe:

#define DELTA_TICKS sample_tick_value 
// initialized somewhere in the code 
DWORD dwStartTick = GetTickCount(); 
DWORD dwEndTick =   GetTickCount() + DELTA_TICKS;     

// The following function fails on a rollover. 
BOOL no_compare_tick_difference() 
{ 
  if ( GetTickCount() > dwEndTick ) 
    return ( TRUE); 
  return (FALSE); 
}

The following code shows how to properly use GetTickCount by comparing tick differences. This code handles the rollover situation.

BOOL compare_tick_difference() 
{ 
  if ( (GetTickCount() – dwStartTick) > DELTA_TICKS) 
    return ( TRUE); 
  return (FALSE); 
}

LoadIcon macht es nicht richtig…

… oder sollte man sagen: Nicht so wie erwartet. 

In einer der Micosoft Newsgroup fand sich eine Anfrage, die sich um folgenden Code drehte:

HICON m_hIcon[2]; 
[...] 
m_hIcon[0] = AfxGetApp()->LoadIcon(IDR_MAINFRAME); 
m_hIcon[1] = AfxGetApp()->LoadIcon(IDR_SMALL); 
[...] 
SetIcon(m_hIcon[0], TRUE);   // Großes Symbol verwenden 
SetIcon(m_hIcon[1], FALSE);  // Kleines Symbol verwenden

Das Problem des Posters war, dass er sich Mühe mit dem Layout eine kleines Icons gegeben hat, aber leider immer nur ein verkleinertes 32×32 Icon verwendet wurde.

Das Problem liegt an der Verwendung von LoadIcon! LoadIcon lädt immer das Standard-Format 32×32. Bzw. in dem Format, dass durch das System als Standard-Icon-Größe vorgegeben wird.

Um es richtig zu machen, muss man das Icon wirklich in der gewünschten Größe laden. Dazu verwendet man die Funktion LoadImage. Eine kleine Helper Routine LoadIconEx kann dann wie folgt aussehen:

HICON LoadIconEx(PCTSTR pszIconName, bool bLargeIcon) 
{ 
 HINSTANCE hInstance = ::AfxFindResourceHandle(pszIconName,RT_GROUP_ICON); 
 return reinterpret_cast<HICON>(::LoadImage( 
       hInstance, 
       pszIconName, 
       IMAGE_ICON, 
       GetSystemMetrics(bLargeIcon ? SM_CXICON : SM_CXSMICON), 
       GetSystemMetrics(bLargeIcon ? SM_CYICON : SM_CYSMICON), 
       0)); 
}

Hotfix für GDI Leaks unter Windows XP-SP2/2003 Server in MFC Applikationen

Unter XP SP2 und Windows 2003 Server kann es bei eingeschalteten Themes zu GDI-Leaks kommen. Speziell wird hier auf MFC Anwendungen hingewiesen (siehe dazu meine Anmerkung unten).

Die Beschreibung und der Download-Link für den Hotfix finden sich hier:
MFC applications leak GDI objects on computers that are running Windows Server 2003 or Windows XP

Anmerkung:

Dies ist ein Hotfix für Theme Handler unter Windows 2003 und Windows XP SP2. Er greift nicht in die MFC ein ❗
Man muss also eigentlich davon ausgehen, dass der Bug im Windows Themes Kern steckt und nichts mit der MFC zu tun hat, sondern eher damit zu tun hat wie in der MFC mit Windows Ressourcen umgegangen wird.
Den Effekt bekommt man ziemlich einfach hin, indem man mit dem Wizard eine MFC-MDI Applikation anlegt. Dann einfach Strg+N festhalten und alle Fenster wieder schließen mit Strg+F4, danach findet man einige Hundert GDI Objekte ausgewiesen im Task-Manager, die vorher nicht da waren.
Ich habe einen Test mit dem MDI-Sample aus dem Petzold gemacht und dieses zeigt diesen Effekt nicht. Evtl. liegt es auch einfach nur an dem Umgang mit den Toolbars. Genaueres konnte ich nicht herausbekommen. 

  • Erstaunlich 1.: Dieser Patch ist mit 2 Jahren doch relativ alt (März 2006) und er ist mir erst durch eine Diskussion in einer Produkt-Gruppe über den Weg gelaufen …
  • Erstaunlich 2.: Dieser Patch wird nicht durch den Windows Update Service installiert, obwohl er in meinen Augen da rein gehört ❗
    Ob nun der Update Service nun den primären Fokus auf Sicherheit hat oder nicht. Ich empfinde dieses Verhalten des Theme Handlers als kritisch!

SYSTEM_FONT, DEFAULT_GUI_FONT und der Font der eigentlich benutzt wird…

Was sind eigentlich  die beiden Fonts SYSTEM_FONT und DEFAULT_GUI_FONT, die durch GetStockObject zurückgegeben werden?
Sind sie ein schneller Weg um an den „MS Shell Dlg“ bzw. „MS Shell Dlg 2“?

Es ist ein Irrtum wenn man glaubt man bekommt den Standard UI Font mit DEFAULT_GUI_FONT oder SYSTEM_FONT. Dieser Irrtum basiert auf der Annahme es gebe nur einen Font den die Windows UI verwendet!

Der richtige Weg vorab: Der einzige korrekte Weg einen richtigen Font für die Default UI zu erhalten ist SystemParametersInfo mit SPI_GETNONCLIENTMETRICS. Bzw., in Dialogen sollte immer als Font „MS Shell Dlg“ bzw. „MS Shell Dlg 2“ verwendet werden (siehe auch The old new thing). Man beachte den Plural ❗

Und was sind diese beiden Fonts nun?
Es sind Relikte aus alten Tagen, die kein Mensch und vor allem kein Windows Entwickler bei Microsoft mehr verwendet.  (Anmerkung des Autors: Ich habe zumindest aus zuverlässiger Quelle gehört, die Entwickler bei Microsoft wären immer noch Menschen 😉 )

  • In alten Tagen von Windows 2.0 wurden SYSTEM_FONT für die Dialoge verwendet. Dieser Font hieß auch System. Man glaubt es kaum, dieser Font ist immer noch der Standard-Dialog-Font, den aber wirklich keiner mehr will. Es ist ein Bitmap Font und er kann nicht mit Anti-Aliasing verwendet werden.
  • Die Geschichte von DEFAULT_GUI_FONT ist weniger spektakulär. Er wurde mit Windows 95  eingeführt und man dachte damit einen Standard gesetzt zu haben. Aber das wurde noch im selben Release zugunsten von SystemParametersInfo  fallen gelassen. Es ist geblieben als weiteres Relikt aus alten Tagen.

Alle Fonts die GetStockObject liefert sind Bitmap Fonts, die auch kein ClearType unterstützen.

Siehe auch:
What are SYSTEM_FONT and DEFAULT_GUI_FONT?
What about logical fonts?
DEFAULT_GUI_FONT really stinks