Kategorie: Windows API

Artikel und Beiträge zur Wndows Programmierung

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 😉

Hotfix für UseMSPrivateAssemblies.h und VC-2008

Einige nutzen ja meine Lösung für private CRT und MFC Assemblies unter VC-2005, die ich in dem diesem Artikel unter Codeproject veröffentlicht habe
http://www.codeproject.com/KB/cpp/PrivateAssemblyProjects.aspx

Das Interesse und die Nachfrage ist groß dieses Verfahren auch unter VC-2008 zu nutzen.
Da ich aber aktuell wenig Zeit habe den Artikel komplett zu überarbeiten, veröffentliche ich den relevanten Code hier erst mal vorab als „Hotfix“. Dieser Hotfix setzt voraus, dass das aktuelle Feature Pack installiert ist. Der Code ist nicht auf die RTM Version hin zugeschnitten und getestet.

UseMSPrivateAssemblies.h

// Version 2.0 by Martin Richter [WWJD]
// Supports VC-2005 and VC-2008
#pragma once    

#ifndef RC_INVOKED
// Avoid problems with the resource compiler if included    

// This defines bock the creation in the header files
#pragma message("Using private assemblies for the MS runtimes")
#define _STL_NOFORCE_MANIFEST
#define _CRT_NOFORCE_MANIFEST
#define _AFX_NOFORCE_MANIFEST
//#define _ATL_NOFORCE_MANIFEST    

// The next statements block the linker from including object files in the
// CRT and the MFC, that would create manifest pragmas too.
#ifdef __cplusplus
extern "C" {            /* Assume C declarations for C++ */
#endif    

__declspec(selectany)       int _forceCRTManifest;
__declspec(selectany)       int _forceMFCManifest;
// __declspec(selectany)    int _forceAtlDllManifest;    

// The next symbols are used by the several versions of VC 9.0
__declspec(selectany)       int _forceCRTManifestRTM;
__declspec(selectany)       int _forceMFCManifestRTM;
__declspec(selectany)       int _forceMFCManifestCUR;    

#ifdef __cplusplus
}                        /* __cplusplus */
#endif    

// We use crtassem.h with the defines there. It just gives us the
// versions and name parts for the dependencies.
// Note that there is also a MFCassem.h but this include file has the
// manifest pragma's already in it. So we can't use it
//
// Three files are controlling this crtassem.h, MFCassem.h and atlassem.h!
// Happily __LIBRARIES_ASSEMBLY_NAME_PREFIX is used in CRT, MFC and ATL!
// Doing it right would need to use _MFC_ASSEMBLY_VERSION for the MFC
// but in fact _CRT_ASSEMBLY_VERSION and _MFC_ASSEMBLY_VERSION and
// _ATL_ASSEMBLY_VERSION are the same
//  - VC-2005 SP1 8.0.50727.762
//  - VC-2008 RTM 9.0.21022.8
//  - VC-2008 Feature Pack 9.0.30411.0 (used if _BIND_TO_CURRENT_VCLIBS_VERSION
//    and _BIND_TO_CURRENT_MFC_VERSION are defined to 1)    

#include <crtassem.h>

// We don't have a seperate block for the Debug version. We just handle
// this with a extra define here.
#ifdef _DEBUG
#define __LIBRARIES_SUB_VERSION    "Debug"
#else
#define __LIBRARIES_SUB_VERSION    ""
#endif    

// Manifest for the CRT
#pragma comment(linker,"/manifestdependency:\"type='win32' "                        \
    "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX "." __LIBRARIES_SUB_VERSION "CRT' "   \
    "version='" _CRT_ASSEMBLY_VERSION "' "                                          \
    "processorArchitecture='x86' \"")    

// Manifest for the MFC
#pragma comment(linker,"/manifestdependency:\"type='win32' "                        \
    "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX "." __LIBRARIES_SUB_VERSION "MFC' "   \
    "version='" _CRT_ASSEMBLY_VERSION "' "                                          \
    "processorArchitecture='x86'\"")    

// #pragma comment(linker,"/manifestdependency:\"type='win32' "                     \
//     "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX ".MFCLOC' "                        \
//     "version='" _CRT_ASSEMBLY_VERSION "' "                                       \
//     "processorArchitecture='x86'\"")    

// Manifest for the ATL
// #pragma comment(linker,"/manifestdependency:\"type='win32' "                     \
//    "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX ".ATL' "                            \
//    "version='" _CRT_ASSEMBLY_VERSION "' "                                        \
//    "processorArchitecture='x86' \"")    

#endif // RC_INVOKED

Anmerkungen:

  • Im Endeffekt sind nur 3 Zeilen (26-28) hinzugekommen.
  • Diese Version funktioniert sowohl für VC-2005 als auch VC-2008!
  • Unter Vista wird allgemein das Problem beobachtet, das private Assemblies nur genutzt werden können, wenn diese in einem Unterverzeichnis liegen. Liegen die Assembly Dateien im gleichen Verzeichnis wie die EXE kommt es zu einem Fehler „The application failed to initialize properly (0xc0000034). „ Dieser Sache bin ich (und andere) auf der Spur.
  • Es spielt für diesen Code keine Rolle ob die beiden Defines _BIND_TO_CURRENT_VCLIBS_VERSION und _BIND_TO_CURRENT_MFC_VERSION gesetzt wurden. Werden diese Defines auf 1 gesetzt bevor UseMSPrivateAssemblies inkludiert wird, dann werden die Manifeste so erzeugt, dass die Feature Pack DLLs gezogen werden. Sind diese beiden Defines nicht gesetzt werden Manifeste für die RTM Version erzeugt.
    Ich empfehle dringend diese beiden Defines zu setzen ❗

Das ist erstmal ein Schnellschuss für alle, die die es etwas eiliger haben.

Der Vorteil gegenüber der Lösung, bei der die Manifeste manuell bearbeitet werden, wie es zum Beispiel Jochen Kalmbach in seinem Blog vorgestellt hat ist klar:
Man muss eben nichts manuell machen 🙂
Es macht wieder alles der Compiler und Linker.

Tipps & Tricks:EXE Dateien in der Eingabeaufforderung/Batches überall zugänglich machen ohne die Verwendung von PATH

Ich verwende sehr oft eine Eingabeaufforderung/Console/CMD.EXE/4-NT Session (wie man es auch nennen mag), weil vieles für mich einfach so schneller geht.
Zudem verwende ich eine Reihe von netten Helferleins (Tools), die zum Teil auch in meinen Buildprozessen integriert sind. Dort wird manchmal auch etwas gemacht was über ein TF CHECKOUT hinausgeht, oder was eben sowieso durch VS in den Path eingetragen wurde.

In den meisten Fällen nutze ich die normalen Installationsroutinen für diese Tools. Das Problem ist dann aber, dass diese Tools sich über X-C:\Program Files\Verzeichnisse verteilen.
Jetzt bei jedem Tool zu wissen wo es installiert ist übersteigt meine Kapazitäten und meine Lust die Pfade einzugeben. Es genügt, wenn ich weiß dass ich die Powertools des TFS mit TFPT aufrufen möchte, oder 7z.
Nun jeden dieser Pfade in PATH einzutragen ist ja wirklich auch nicht der Schreier. Das ganze wegen einer EXE…

Es gibt einen einfachen Weg sich Tools so zu behandeln, dass man sie von überall aufrufen kann. Dieser Weg ist in der Shell verborgen und lautet:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\
Jeder, der schon mal ein Installationsprogramm geschrieben hat kennt diesen Eintrag.

Was man zu tun hat ist ganz simpel: Man erzeugt einfach über RegEdit.exe in diesem Ast einen neuen Schlüssel mit dem Namen der EXE, die man gerne überall benutzen möchte (z.B. 7Z.EXE oder TFPT.EXE). Auf der rechten Seite als Standardwert trägt man einfach den vollständigen Pfad ein, wo diese EXE zu finden ist (in meinem Beispiel also: C:\Program Files\7-Zip\7z.exe oder eben C:\Program Files\Microsoft Team Foundation Server 2008 Power Tools\TFPT.exe).
So einfach kann es manchmal sein 😉

BTW: Leider geht das ganze nicht mit
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\!
Es gibt zwar einige dämliche Programme, die hier Eintragungen machen, allerdings haben die keine Wirkung.

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

Debugging und ASSERTs in Services

Ich habe in der letzten Zeit einige COM-PlugIns  und Service Komponenten entwickelt. Alles Teile von anderen Diensten und TSPs (Tapi Service Provider). D.h. alles ohne UI. Die ganze Maschinerie, die ich hierzu verwendete befand sich auf einem Windows 2003 R2 Server. Aufgrund bestimmter Hardware war ein virtueller Server zum Testen nicht drin.
Macht ja nix. Man kann ja auch mit Remote Desktop auf dem Server vom eigenen Platz aus arbeiten, ohne deshalb im klimatisierten und immer zu kaltem und außerdem viel zu lautem Serverraum zu arbeiten…

Ziemlich schnell nervte mich gleich ein bestimmtes Problem. Ein Service mit einer meiner Komponenten stand auf einmal. Ich habe mich mit dem Debugger remote attached und merkte mehr oder weniger schnell, dass ein bestimmter Thread (von 67) auf einen ASSERT gelaufen war. Dämlicher Weise hatte der nun kein DebugBreak ausgelöst. Genaugenommen stand der Thread in einer MessageBox mit dem ASSERT Fenster, dass jeder kennt.
Da ich aber per Remote Session mit dem Server verbunden war sah ich diese nicht. Wäre ich am primären Monitor angemeldet gewesen, hätte mich die MessageBox erreicht, dafür trifft die CRT Vorsorge.
Dämlich! Mir wäre sogar ein Crash (mit Minidump natürlich) lieber gewesen. So stand der Service blockierte noch drei andere Sachen und es dauerte doch einige Zeit bis ich diesen stehenden Service als Ursache ausmachen konnte. Wäre der Service gecrasht hätte ich es in Sekunden mitbekommen.

OK! Wie gestalte ich das System nun um, dass ein ASSERT immer einen DebugBreak auslöst und keine MessageBox, die sowieso keiner zu sehen bekommt?
Das würde einen Minidump schreiben und wenn ich mit dem Debugger verbunden wäre, würde es sofort das System an der entsprechenden Stelle stoppen. Die MessageBox mit dem ASSERT brauche ich nicht.

Ein wenig Lesen in der CRT Doku schadet nicht. Also hier die Lösung:

Schritt 1: Wir verhindern, dass die entsprechende MessageBox erscheint und stellen entsprechend ein, dass der ASSERT in der Debug Ausgabe mit protokolliert wird. Und wenn man es hat auch noch will, zusätzlich in einer Protokolldatei.

_CrtSetReportMode(_CRT_ASSERT,_CRTDBG_MODE_DEBUG/*|_CRTDBG_MODE_FILE*/);

Schritt 2: Nun brauchen wir noch einen DebugBreak, der immer ausgelöst wird. Auch das ist kein Problem. Wir benutzen den Debug Report Hook:

_CrtSetReportHook2(_CRT_RPTHOOK_INSTALL, MyDebugHook);

MyDebugHook ist nun nichts weiter als eine kleine Funktion die nur eins enthält: den Aufruf der Funktion DebugBreak();.

So ausgestattet lassen sich Services im Debugmode weitaus besser entwickeln. Jetzt sorgen Sie wenigstens für einen anständigen Crash (natürlich mit Dump), wenn es ASSERTet… :mrgreen:

Late Binding und schwache Performance durch GetIDsOfNames

Immer wieder sehe ich Entwickler, die über Late Binding COM Komponenten ansprechen. Das ist an sich nur zu unterstützen, denn DISPIDs können sich schnell mal ändern, wenn sich ein Interface ändert. Gerade bei den rasant an Verbreitung zunehmenden .NET Komponenten, die man mal schnell in die eigene Anwendung per COM einbindet, kann das Binding über die Interfaces und DISPIDs schnell zum Frust werden. Gleiches gilt für Office Komponenten, bei denen man sich nicht zwingend an ein Interface binden will. Zudem ist es der von Microsoft empfohlene Weg die Office-Automation zu benutzen (siehe auch hier).

OK! Also man nimmt Late Binding und verwendet z.B. die aktuellen Wrapper, die netterweise von der ATL zur Verfügung gestellt werden,  z.B. die netten Funktionen aus der CComDispatchDriver Klasse. GetPropertyByName, PutPropertyByName und auch die Funktionen Invoke0, Invoke1 und InvokeN haben entsprechende Überladungen, die die Verwendung von Funktions-/Eigenschaftsnamen direkt erlauben.

Der Nachteil liegt nicht gleich auf der Hand. Immer wenn solch eine Funktion aufgerufen wird, wird nicht durch der IDispatch::Involke ausgeführt, sondern auch ein Aufruf von IDispatch::GetIDsOfNames. Bei einem Out-Of-Process-Server kann dieser Roundtrip einiges an Performance kosten. Dabei ist es so einfach es besser zu machen.

Die Doku von IDispatch::GetIDsOfNames sagt folgendes:  

The member and parameter DISPIDs must remain constant for the lifetime of the object. This allows a client to obtain the DISPIDs once, and cache them for later use.

Und wer den oben genannten KB-Artikel aufmerksam gelesen hat, der hat auch was von DISPID-Caching mitbekommen.

Ich benutze gerne die die Wrapper, die in der MFC automatisch erzeugt werden, wenn man einen Type-Library über den Class View importiert. Hier werden die Funktionen auch in eine nette kleine COleDispatchDriver-Klasse verpackt und man bekommt netterweise ein gutes Exception Handling den Fehlerfall geliefert. Leider werden hier aber auch wieder nur DISPIDs verwendet.
Aber mit einem kleinen Trick, kann man diese Klassen genial einfach für Late Binding nutzen. Ich gehe wie folgt vor:

  • Ich importiere die Type-Library (tlb) mit dem Visual Studio Class View.
  • D.h. ich habe jetzt alle Wrapper mit DISPIDs, Was ich eigentlich für Late Binding vermeiden will.
  • Jetzt passe ich einfach die einzelnen Wrapper Funktionen in der folgenden Art und Weise an, ich ersetze die DISPID durch eine statische Variable:
void CMyWrapper::DoSomething(){
  static CDispIdHolder dispid(m_lpDispatch,L"DoSomething");
  InvokeHelper(dispid, DISPATCH_METHOD, VT_EMPTY, NULL, NULL);
}
  • Die kleine Klasse die ich hier verwende macht nun den Rest und besorgt die DISPID und cached sie damit weil die Variable statisch definiert ist:
class CDispIdHolder
{
public:
 CDispIdHolder(IDispatch *pDispatch,LPCOLESTR pName)
  : m_dispid(DISPID_UNKNOWN)
  {
   HRESULT hr = pDispatch->GetIDsOfNames(
         IID_NULL,
         &const_cast<LPOLESTR>(pName),
         1,
         LOCALE_SYSTEM_DEFAULT,
         &m_dispid);
   if (FAILED(hr))
    AfxThrowOleException(hr);
  }
  operator DISPID() { return m_dispid; }
private:
 DISPID m_dispid;
};

Die Exception, die man verwendet ist natürlich Implementierungsfrage.

❗ Der Performance Gain ist zum Teil beträchtlich, besonders wnen bestimmte Funktionen sehr oft aufgerufen werden müssen!

Anmerkung (für alle die es ganz genau nehmen):
Wenn man die Doku genau liest, heißt es natürlich hier, dass die Implementierung nur für die Lebenszeit des Objektes konstante DISPIDs garantiert. Wenn man allerdings bei Early Binding schon DISPIDs als konstant annimmt, ist meine Methode für Late Binding sicherlich vertretbar.