Das Web Browser Control stiehlt den Fokus wenn ein Dokument geladen wurde

Wenn man ein Web Browser Control einbindet und dieses eine Seite lädt, dann wird der Fokus in dieses Browser Control gesetzt. Dagegen ist kein Kraut und keine Notification gewachsen.
Genaugenommen ist nicht das Webbrowser Control schuld, sondern der Scriptcode der auf der Seite läuft und den Fokus umsetzt. Das sieht man schnell wenn man den Moment der WM_KILLFOCUS Nachricht im Debugger abpasst und sich den Stacktrace ansieht.

0013b84c 4a570824 USER32!NtUserSetFocus 
0013b858 4a5ce628 mshtml!CDoc::TakeFocus+0x2a 
0013b880 4a63fc0b mshtml!CElement::BecomeCurrent+0x167 
0013b8b4 4a63fb72 mshtml!CElement::focusHelper+0xcc 
0013b8c0 4a587c85 mshtml!CElement::focus+0x1d 
0013b8cc 4a5d7477 mshtml!Method_void_void+0x17 
0013b94c 4a57fae8 mshtml!CBase::ContextInvokeEx+0x462 
0013b97c 4a575413 mshtml!CElement::ContextInvokeEx+0x72 
0013b9b0 76fa5295 mshtml!CElement::ContextThunk_InvokeEx+0x44 
0013b9e8 76fa5208 jscript!IDispatchExInvokeEx2+0xa9 
0013ba20 76fa5323 jscript!IDispatchExInvokeEx+0x56 
0013ba90 76fa577b jscript!InvokeDispatchEx+0x78 
0013bad8 76fa57c6 jscript!VAR::InvokeByName+0x1c1 
0013bb18 76fa4ab0 jscript!VAR::InvokeDispName+0x43 
0013bb3c 76fa5a14 jscript!VAR::InvokeByDispID+0xfb 
0013bd30 76fa46d8 jscript!CScriptRuntime::Run+0x195b 
0013bdf4 76fa506e jscript!ScrFncObj::Call+0x69 
0013be6c 76fa5f6a jscript!CSession::Execute+0xb8 
0013bf6c 76fa672f jscript!NameTbl::InvokeDef+0x183 
0013c040 76fa5295 jscript!NameTbl::InvokeEx+0xd2

Dummerweise gibt es kein Event mehr, das danach gefeuert wird, wenn der Skript-Code abläuft. Das letzte Event bevor das aktive Fenster den Fokus verliert ist OnDocumentComplete.

Es gibt auch einige Threads die dieses Thema behandeln, aber keine vernünftige Lösung. Von so manchen Timerlösungen halte ich nichts, die da so vorgeschlagen werden, wer weiß schon wann eine Seite geladen ist?
Besonders ärgerlich auch, wenn man das Browser Control nicht mal auf einem sichtbaren Fenster hat, sondern nur in einem versteckten Fenster hält. Auch in diesem Fall verliert das aktive Fenster den Fokus.

Aber mit einem kleinen Trick bekommt man es doch hin ( 🙂 warum sonst schreibe ich den Artikel )

  1. Man baut einen OnDocumentComplete Handler ein.
  2. Wenn das Event eintritt, besorgt man sich mit GetFocus das Fenster, dass aktuell noch den Fokus inne hat.
  3. Nun sendet man mit PostMessage eine selbst definierte Nachricht (#define WM_RESTOREFOCUS (WM_APP+x)) an den Container des Webbrowser Controls und übergibt als wParam einfach das Handle des Fensters, dass man soeben mit GetFocus ermittelt hat.
  4. Nach diesem Event wird der Skript-Code ausgeführt, der den Fokus stiehlt. Das stört uns nicht.
  5. Irgendwann kommt die Messageloop jetzt wieder an die Reihe und zieht die benutzerdefinierte Nachricht WM_RESTOREFOCUS aus der Queue.
  6. Man hat natürlich einen Handler für diese Nachricht im Container des Webbrowser Controls. Dieser macht nun nichts anderes als einen SetFocus auf das HWND Handle auszuführen, das im wParam übergeben wurde. Ein Test zuvor mit IsWindow versteht sich von selbst.

Dadurch, dass die Nachricht in der Message-Queue gepostet wird, wird sie zeitnah ausgeführt sobald wirklich der User wieder eine Chance selbst Eingaben zu machen. Problem zufriedenstellend gelöst.

Das sollte sich sogar mit C# oder VB hinbekommen lassen 😉

LVM_GETSUBITEMRECT mit LVIR_ICON liefert andere Ergebnisse unter Vista als unter XP

Das damit auch die Funktion CListCtrl::GetSubItemRect aus der MFC betroffen ist, ist dann auch  klar.
Manche Sachen ärgern einen einfach. Vor allem wenn man nichts am Code ändert und doch falsches Verhalten erntet.

Wieder mal ist die Vista UI eigentümlich ungereimt, in diesem Fall bei einem List View.

Folgendes ist gegeben:

  • Ein List View (SysListView32) in einem Dialog oder anderen Fenster
  • Der List View hat den Stil LVS_REPORT
  • Der List View hat hat mehr als eine Spalte.
  • Dem List View wurde eine Imagelist zugewiesen.

Führt man nun auf Windows XP LVM_GETSUBITEMRECT /CListCtrl::GetSubItemRect mit LVIR_ICON aus, dann erhält man immer ein Rectangle zurück mit der entsprechenden Weite der Imagelist Symbole. Das Verhalten ist:

  • vollkommen unabhängig ob ein Manifest für COMCTL32.DLL Version 6.0 vorhanden ist oder nicht
  •  es ist auch unabhängig ob LVS_EX_SUBITEMIMAGES gesetzt ist oder nicht.

Macht man das ganze unter Vista, dann liefert LVM_GETSUBITEMRECT /CListCtrl::GetSubbItemRect ein RECT / CRect mit der Weite der Symbole immer dann wenn:

  • kein Manifest für COMCTL32.DLL Version 6.0 vorhanden ist
  • oder LVS_EX_SUBITEMIMAGES gesetzt ist

Das heißt in dem Fall

  • ein Manifest für COMCTL32.DLL Version 6.0 ist
  • und LVS_EX_SUBITEMIMAGES ist nicht gesetzt .

erhält  man ein Rectangle mit der Weite 0 (Null) 😕

Anmerkung:
 Man kann sich natürlich streiten was nun richtig ist. Wenn LVS_EX_SUBITEMIMAGES nicht gesetzt ist, dann macht LVIR_ICON zugegebenermaßen wenig Sinn. Aber es leuchtet irgendwie nicht ein, dass ohne Manifest und ohne LVS_EX_SUBITEMIMAGES, wieder ein Wert zurückgeliefert wird. Entweder ist die Weite von LVS_EX_SUBITEMIMAGES abhängig oder eben nicht.
Das Ganze ist in jedem Falle mal ungereimt und nicht kompatibel ❗

Nachtrag 26.03.2009:
Das List-Control liefert für das Subitem 0 immer ein korrektes Rectangle für LVIR_ICON! Nur wenn wirklich ein Subitem (>0) abgefragt wird, tritt das Problem auf.

Memory Dumps on the fly

Ich hatte in einem unserer Release-Kandidaten ein massives Problem. In bestimmten nicht reproduzierbaren Situationen, blieb zeitgleich auf allen angeschlossenen Arbeitsstationen das Programm stehen. Und nun?

Der Deadlock, der auftrat war so fatal, dass ich nicht mal mehr über eine versteckte Funktion einen Speicherdump auslösen konnte. Dazu verwende intern üblicherweise eine reservierte Tastenkombination. Nur wenn keine Nachrichten mehr abgearbeitet werden, gibt es auch keine Funktionen, die man per Tastatur aufrufen kann.

Glücklicherweise wurde auf allen betroffen Rechner Windows Vista eingesetzt. Und die Lösung für diesen Fall ist unter Vista so einfach wie genial. Im Task-Manager unter Vista findet sich im Kontextmenü ein unauffälliger Menüpunkt: „Abbilddatei erzeugen“:

Memory dump on demand

Jupp! Er macht genau was ich brauchte. Durch diesen netten Befehl wird im %TEMP% Verzeichnis des Benutzers ein voller Speicherdump erzeugt.

Ich musste von 6 Dumps genau 2 durchsehen, bis ich das Problem lokalisiert hatte.
Eine wirklich nette und nützliche Funktion des Taskmanagers.

Unter Windows XP kann man ähnliches machen nur ist es hier ungleich komplizierter, aber es geht auch mit dem mitgelieferten symbolischen Debugger NTSD und den folgenden Schritten:

  • PID über den Task-Manager ermitteln (entsprechende Spalte einblenden lassen)
  • NTSD starten mit der entsprechenden PID
    NTSD -p 4656
  • Dump erzeugen:

    0:001> .dump /f c:\temp\crash\full.dmp
    Creating c:\temp\crash\full.dmp – user full dump
  • Wird der Debugger mit Quit (q) verlassen wird auch der Prozess beendet.

Selbst reingelegt beim Test von „XP oder später“

Manche Codezeilen schreibt man ja einfach im Schlaf so in etwa wie diesen hier

static const OSVERSIONINFO &GetOSVersionInfo()
{
 static OSVERSIONINFO osVersionInfo;
 if (osVersionInfo.dwOSVersionInfoSize==0)
 {
  osVersionInfo.dwOSVersionInfoSize = sizeof(osVersionInfo);
  ::GetVersionEx(&osVersionInfo);
 }
 // return pointer to struct
 return osVersionInfo;
}

bool OSIsWinXP()
{
 // Check if OS is XP or later
 const OSVERSIONINFO &osvi= GetOSVersionInfo();
 return (osvi.dwPlatformId & VER_PLATFORM_WIN32_NT)!=0 &&
     osvi.dwMajorVersion>=5 &&
     osvi.dwMinorVersion>=1;
}

Der Sinn und Zweck ist eindeutig. Ich benötige diese Funktion um zu Testen ob Windows XP oder ein späteres OS wie Vista oder Windows 7 installiert ist. Dumm nur das dieser Code dämlich falsch ist.
Die Betriebssysteme haben die folgenden internen Versionsnummern
5.0 – Windows 2000
5.1 – Windows XP
5.2 – Windows Server 2003
6.0 – Windows Vista
6.1 – Windows 7 (Anmerkung: idotisch, dass hier nicht 7.0 verwendet wird)

Als ich den Code schrieb war Windows XP gerade draußen und selbst Windows Server 2003 gerade am Horizont. Dämlicherweise schrieb ich in dem Test osvi.dwMajorVersion>=5 && osvi.dwMinorVersion>=1.
ohne natürlich daran zu denken, dass ein späteres OS wieder mit einer 0 als minor Version kommen könnte.
Dadurch ergibt sich natürlich das der Test für alle Betriebssysteme nach Windows XP funktioniert nur nicht für Windows Vista  weil eben die Minor Version hier 0 ist. Ich war drauf und dran mal wieder einen Bug einzureichen bis mir schlagartig klar war, dass nicht Vista einen Fehler hat sondern mein eigener Code.

Der korrekte Test muss natürlich so lauten:

bool OSIsWinXP()
{
 // Check if OS is XP or later
 const OSVERSIONINFO &osvi= GetOSVersionInfo();
 return (osvi.dwPlatformId & VER_PLATFORM_WIN32_NT)!=0 &&
   (osvi.dwMajorVersion>5 ||    // May be vista or later
       (osvi.dwMajorVersion==5 &&    // that's XP
        osvi.dwMinorVersion>=1));
}

Code wie im Schlaf zu schreiben bringt es manchmal eben nicht. 😉

Tooltips und Customdraw

Customdraw ist für mich erste Wahl, wenn es um das Anpassen von Ausgaben in Controls geht, zudem ein subclassing von WM_PAINT mit Erhalt der Grundfunktionen eigentlich nicht möglich ist (ich werde dazu demnächst noch mal schreiben).

Liest man die Anleitung zu NM_CUSTOMDRAW und Tooltips, bekommt man den Eindruck, dass man wie bei einem List Control an jeder Stelle eingreifen kann. Vor dem Zeichnen, nach Löschen des Hintergrundes und so weiter: CDRF_NOTIFYITEMDRAW, CDRF_NOTIFYPOSTERASE, CDRF_NOTIFYPOSTPAINT, CDRF_NOTIFYSUBITEMDRAW werden in der Doku erwähnt.

Diese Informationen sind komplett irreführend, denn nur CDRF_NOTIFYPOSTPAINT wird vom Tooltip akzeptiert und beachtet. Man kann z.B. nicht auf die Ausgabe des Textes alleine übernehmen und nur das Löschen des Hintergrundes dem Control überlassen. Es wird wirklich nur CDRF_NOTIFYPOSTPAINT berücksichtigt ( ich habe mich durch den Assembler-Code der COMCTL32.DLL durch gedebuggt).
Auch die Rückgabe von CDRF_NEWFONT kann man sich sparen. Man muss nur einen neuen Font selektieren und er wird berücksichtigt.

Was in der Dokumentation auch zu kurz kommt, ist, dass NM_CUSTOMDRAW mit CDDS_PREPAINT zweimal kurz hintereinander aufgerufen wird. Beim ersten Mal ist DT_CALCRECT in NMTTCUSTOMDRAW::uDrawFlags gesetzt ist und beim zweiten mal nicht mehr. Man hat dadurch die Möglichkeit die Größe des Controls mit NMCUSTOMDRAW::rc zu kontrollieren. Gut beschrieben ist das nicht in der MSDN sondern in einem alten Artikel des MSJ aus dem Otkober 1996, wer weiß wann der verschwinden wird.

Die Implementierung hier ist einfach halbherzig, leider. Die Möglichkeiten wären so genial, hier ein bisschen Fettgedrucktes, dort noch mal ein Icon… Schade…

Der etwas bessere CMemDC

CMemDC aus dem Artikel Flicker free drawing with MFC ist wohl der Klassiker für Doublebuffering und ist wohl jedem MFC Entwickler bekannt.

Er macht was er soll und ich habe ihn selbst über Jahre hinweg unverändert verwendet. Solange man einfache Sachen macht und ausschließlich den MM_TEXT Mappingmode verwendet ist alles OK.
Hat man sich aber was spezielles – zoomfähiges – zusammengebaut mit MM_ANISOTROPIC dann funktioniert das Ganze nicht mehr, weil Keith an den Window Origin Koordinaten dreht und nicht am Viewport.

Meine abgewandelte Variante trägt einer entsprechende Verwendung auch für andere Mappingmodes Rechnung. Es müsste IMHO für jeden funktionieren. Intensiv getestet habe ich es mit MM_ANISOTROPIC.

Will/muss man auch an den Viewport Koordinaten drehen, dann sollten die alten Viewport Koordinaten gelesen werden und dann entsprechend durch ein Offset geändert werden.
Alles anderen Werte wie die Extents können beliebig verändert werden.
Bei der Verwendung sollte MM_TEXT eingeschaltet sein (entsprechende ASSERTs habe ich ergänzt). MM_TEXT ist normalerweise gesetzt, wenn CMemDC direkt nach Instanzierung des CPaintDC zum Einsatz kommt. Der Destruktor setzt dann den Mappingmode auf MM_TEXT zurück.

Dieser neue, modifizierte CMemDC kann einfach die bisherige Implementierung ersetzen.

Have fun & Happy coding 🙂

class CMemDC : public CDC
{
public:
  // constructor sets up the memory DC
  CMemDC(CDC* pDC)
    : CDC()
    , m_pDC(pDC)
    , m_pOldBitmap(NULL)
    , m_bMemDC(!m_pDC->IsPrinting())
  {
    ASSERT(pDC != NULL);

    if (m_bMemDC)
    {
      // Create a Memory DC.
      // At this moment we should have mapping mode text
      ASSERT(m_pDC->GetMapMode()==MM_TEXT);
      ASSERT(m_pDC->GetWindowOrg()==CPoint(0,0));
      ASSERT(m_pDC->GetViewportOrg()==CPoint(0,0));

      // Get the clip box and create bitmap for this size
      m_pDC->GetClipBox(&m_rect);
      CreateCompatibleDC(m_pDC);
      m_bitmap.CreateCompatibleBitmap(m_pDC, 
              m_rect.Width(), m_rect.Height());
      m_pOldBitmap = SelectObject(&m_bitmap);

      // Adjust the view port so that we hit the clip rect.
      SetViewportOrg(-m_rect.left, -m_rect.top);
      IntersectClipRect(m_rect);

      // Fill background in case the user has overridden
      // WM_ERASEBKGND.  We end up with garbage otherwise.
      FillSolidRect(m_rect, m_pDC->GetBkColor());
    }
    else
    {
      // Make a copy of the relevant parts of the current DC for printing
      m_bPrinting = m_pDC->m_bPrinting;
      m_hDC     = m_pDC->m_hDC;
      m_hAttribDC = m_pDC->m_hAttribDC;
    }
  }

  // Destructor copies the contents of the mem DC to the original DC
  ~CMemDC()
  {
    if (m_bMemDC)
    {
      // The mapping mode might effect the BitBlt. So we need to return to
      // MM_TEXT. This makes m_rect.left and m_rect.top again the
      // coordinates of our clipped rectangle. And to make sure that the
      // coordinates are really used we just clear the ViewportOrg and the
      // WindowOrg
      SetMapMode(MM_TEXT);
      SetViewportOrg(0,0);
      SetWindowOrg(0,0);

      // Copy the off screen bitmap onto the screen.
      // For this we just make sure that we really target the rectangle of
      // our temporal bitmap.
      m_pDC->BitBlt(m_rect.left, m_rect.top, 
              m_rect.Width(), m_rect.Height(),
              this, 0, 0, SRCCOPY);

      //Swap back the original bitmap.
      SelectObject(m_pOldBitmap);
    }
    else
    {
      // All we need to do is replace the DC with an illegal value,
      // this keeps us from accidentally deleting the handles associated
      // with the CDC that was passed to the constructor.
      m_hDC = m_hAttribDC = NULL;
    }
  }

  // Allow usage as a pointer
  CMemDC* operator->()  {   return this;  }

  // Allow usage as a pointer
  operator CMemDC*()  {   return this;  }

private:
  CBitmap  m_bitmap;    // Offscreen bitmap
  CBitmap* m_pOldBitmap;  // bitmap originally found in CMemDC
  CDC*   m_pDC;     // Saves CDC passed in constructor
  CRect  m_rect;    // Rectangle of drawing area.
  bool   m_bMemDC;    // true if CDC really is a Memory DC.
};

Externe und interne COM Zugriffe unterscheiden

Ich benutze als interne Makrosprache gerne VBScript. D.h. ich hoste VBScript.
Ich biete dann bestimmte COM-Objekte (IDisptach) an, die es dem Nutzer erlauben mein  Programm anzupassen oder intern zu steuern.

Nun macht es aber unter Umständen einen gravierenden Unterschied, ob ein COM-Objekt von einem programminternen Nutzer, oder von extern angesprochen wird. Intern möchte ich zum Beispiel mehr  oder andere Funktionen erlauben als durch einen externen Zugriff von einem anderen Programm oder Skript.

Wie kann man aber unterscheiden von wo ein COM Zugriff erfolgt ❓

Netterweise hat COM die Funktion CoGetCallContext, die mir genau diese Info liefert. Liefert CoGetCallContext S_OK und damit einen Interfacezeiger auf IServerSecurity, dann wurde der COM Zugriff von einem externen Prozess abgesetzt. Wenn CoGetCallObject E_NOINTERFACE zurück gibt haben wir einen internen Aufruf aus dem eigenen Prozess heraus.

bool IsExternalComCall()
{
 // get context
 CComPtr<IServerSecurity> spSecurity;
 HRESULT hr = ::CoGetCallContext(IID_IServerSecurity,
                      reinterpret_cast<void**>(&spSecurity));
 return SUCCEEDED(hr);
}

Herzlichen Dank an René König für diesen Ansatz, den er mir in microsoft.public.de.vc gab.

Aus zwei mach eins: Wie man zwei Cursor kombinieren kann

Wer komplexere UIs baut, der kommt um Drag&Drop oder andere Extrafunktionen mit der Maus nicht herum. Um den Benutzer gut zu unterstützen verwendet man natürlich auch spezielle Cursor.
Auffällig ist aber oft genug der Unterschied zwischen den schönen Standardzeigern im 3D-Stil und den oft flachen Zeigern, die gerade mal zusätzlich ein Plus oder ein Stoppzeichen tragen. Oder ganz und gar der Unterschied , wenn man eigene Cursorstile verwendet, wie z.B. Dirigent oder Hände.

Ich habe mich bei meinem aktuellen Projekt gefragt, warum man eigentlich nicht den aktuellen Standard-Cursor verwendet und diesen zusätzlich mit dem entsprechenden Symbol versieht (Pluszeichen, Stopp, Dragframe etc). Das würde besser aussehen und Arbeit sparen, weil man sich nur noch Gedanken um die Extrasymbolik machen muss und der Benutzer behält seinen eingestellten normalen Cursor.

Schaut man sich den Explorer unter XP+Vista an, dann macht man die Entdeckung, dass der es genauso macht. Der aktuelle Cursor wird beim Drag&Drop Vorgang um ein Stopp- oder Pluszeichen ergänzt.

Warum es also nicht selber auch so machen ❓

Meine Suche im Internet zu diesem Thema: „Wie kombiniert man zwei Cursor zu einem?“, war nicht von Erfolg gekrönt. Beispielcode dazu habe ich nicht gefunden. Aber auch wirklich gar nichts.
Also selbst Hand anlegen.

Bei meinem ersten Versuch wollte ich die Cursor-Bitmaps direkt manipulieren. Bei meiner Untersuchung und dem ersten Democode wurde klar, dass Windows gar keinen Unterschied mehr zwischen Icons und Cursor macht. Erstaunlich ❗ Ob Icon oder Cursor spielt eigentlich keine Rolle. HCURSOR und HICON sind identische Typedefs. Also egal ob toller Farbcursor oder monochromer Cursor, alles gleich.
Mit dieser Entdeckung nahm ich schnell Abstand von BitBlt und Konsorten und verwendete eine Imagelist, die genau diese Funktion des Overlays von Symbolen bereits unterstützt und zudem auch noch perfekt mit Icons umgehen kann.

Herausgekommen ist der folgende Code, der es erlaubt zwei Icons, oder Cursor zu überlagern und ein neues Icon oder einen neuen Cursor zu erzeugen.

Man muss sich aso nur mit LoadCursor, den aktuellen Cursor laden und kann diesen damit ganz einfach modifzieren. Nicht vergessen: Das erzeugte Icon/Cursor muss allerdings mit DestroyIcon auch wieder entsorgt werden. Das Ganze habe ich der Einfachheit halber mit MFC Funktionen geschrieben, aber das Ganze in pure WinAPI zu transformieren dürfte nicht schwer sein. 😉

 Hier nun der Code. Have fun!

HICON CombineIcons(HICON hIcon1, HICON hIcon2)
{
 // Remember that HCURSOR and HICON are identical!
 // hIcon1 is overlayed by hIcon2.
 // hIcon2 isn't adjusted in size or position.
 // It just overlays hIcon1
 // Get bitmaps of icon 1
 ICONINFO iconInfo;
 ::ZeroMemory(&iconInfo,sizeof(iconInfo));
 if (!GetIconInfo(hIcon1,&iconInfo))
  return NULL;

 // Attach the bitmaps to get them automatically freed
 // upon error.
 CBitmap bitmap, mask;
 bitmap.Attach(iconInfo.hbmColor);
 mask.Attach(iconInfo.hbmMask);

 // Get size and width
 BITMAP bm;
 if (bitmap.m_hObject)
  bitmap.GetObject(sizeof(bm),&bm);
 else
  mask.GetObject(sizeof(bm),&bm);

 // Get the color depth from the icon and create an image list
 // Remember we need a
 UINT flags = 0;
 switch (bm.bmBitsPixel)
 {
 case 4:  flags = ILC_COLOR4;  break;
 case 8:  flags = ILC_COLOR8;  break;
 case 16: flags = ILC_COLOR16; break;
 case 24: flags = ILC_COLOR24; break;
 case 32: flags = ILC_COLOR32; break;
 default: flags = ILC_COLOR4;  break;  
 }
 CImageList il;
 // be ware that the monochrom cursor bitmap is twice the height
 if (!il.Create(bm.bmWidth,
      bm.bmHeight/(iconInfo.hbmColor!=NULL ? 1 : 2),
      ILC_MASK|flags,2,2))
  return NULL;

 // Load the both icons into the image list
 il.Add(hIcon1);
 il.Add(hIcon2);

 // Define the second icon as an overlay image
 il.SetOverlayImage(1,1);

 // Get a new icon with icon 2 overlayed
 HICON hCombined = ImageList_GetIcon(il.m_hImageList,0,
              ILD_NORMAL|INDEXTOOVERLAYMASK(1));
 if (!hCombined)
  return NULL;

 // Need the icon infos for this new icon
 ICONINFO iconInfoCombined;
 ::ZeroMemory(&iconInfoCombined,sizeof(iconInfo));
 if (!GetIconInfo(hCombined,&iconInfoCombined))
  return NULL;

 // Destroy the combined icon, we just have the bitmap and the mask
 ::DestroyIcon(hCombined);

 // Get the bitmaps into objects to get them automatically freed
 CBitmap bitmapCombined, maskCombined;
 bitmapCombined.Attach(iconInfo.hbmColor);
 maskCombined.Attach(iconInfo.hbmMask);

 // Get the hotspotinto and cursor data from
 // the ICONINFO of hCursor1
 iconInfoCombined.fIcon = iconInfo.fIcon;
 iconInfoCombined.xHotspot = iconInfo.xHotspot;
 iconInfoCombined.yHotspot = iconInfo.yHotspot;

 // OK we have can create a new Cursor out of the target
 // Don't forget to use DestroyIcon for the new Cursor/Icon
 return ::CreateIconIndirect(&iconInfoCombined);
}

VS Tipps & Tricks: Heap Bugs finden (Teil 4)

In meine ersten Artikeln über Heap-Bugs habe ich bereits erwähnt, dass die CRT aber auch Windows selbst Speicher unter bestimmten Umständen vorbelegt bzw. beim Freigeben des Speichers mit einem festen Wert löscht.

Für einen Entwickler ist es gut zu wissen welche Werte durch wen gesetzt werden. Zudem erleichtert einem dieses Wissen auch das Debuggen und die Identifikation von Problemen im Zusammenhang mit dem Heap, deshalb habe ich hier mal diese Magic-Bytes, die von Microsoft verwendet werden hier zusammengetragen.

Würde man im Debugger zum Beispiel eine Variable mit dem Wert 0xCCCCCCCC entdecken, dann ist davon auszugehen, dass man diese Variable auf dem Stack nicht initialisiert hat.

  • 0xABABABAB
    Wird von HeapAlloc als Wert für die Guard Bytes („no man’s land“) vor und hinter Speicherblöcken verwendet.
  • 0xBAADF00D
    Wird von LocalAlloc(LMEM_FIXED) verwendet um nicht nicht initialisierten Speicher im Heap zu kennzeichnen.
  • 0xCCCCCCCC
    Wird von der Debug-CRT verwendet um nicht initialisierten Stack zu kennzeichnen.
  • 0xCDCDCDCD
    Wird von der Debug-CRT verwendet um nicht initialisierten Speicher im Heap zu kennzeichnen.
  • 0xDDDDDDDD
    Wird von der Debug-CRT verwendet um freigegebenen Speicher im Heap zu kennzeichnen.
  • 0xFDFDFDFD
    Wird von vom Debug-Heap verwendet für Guard Bytes („no man’s land“), vor und hinter Speicherblöcken.
  • 0xFEEEFEEE
    Wird von HeapFree() verwendet um freigegebenen Speicher zu kennzeichnen.

Siehe auch: http://en.wikipedia.org/wiki/Magic_number_(programming)

CFileDialog öffnet unter Umständen nicht

Ein Problem bei einem Kunden hat mich ins ungläubige Staunen getrieben.
Wir haben in einem Einstellungsdialog ein Edit Control für einen Dateinamen. Dazu einen simplen Schalter mit dem man einen CFileDialog öffnet und die Datei so auswählen kann. Bei einem Kunden wollte aber der Dialog in einigen Fällen nicht öffnen, der Klick auf den Schalter blieb ohne Wirkung. Da der entsprechende Code so simpel war, kam ein Programmfehler kaum in Frage.

Nachdem ich mir einen Screenshot habe senden lassen, staunte ich nicht schlecht, denn ich konnte den Fehler mit gleichen Eingaben zuerst nicht nachvollziehen, denn ich nutzte Vista und der Kunde hatte XP SP2. Sobald ich aber unter XP die selben Vorgaben machte, trat der Fehler auch bei mir auf.

Es scheint ein Bug in den Common Dialogs zu sein. Ist der Dateiname, den man im zweiten Parameter von CFileDialog angibt (vorschlägt) in bestimmter Weise „ungültig“, dann öffnet der Dialog nicht. Der Rückgabewert ist IDCANCEL (2) und CommDlgExtendedError liefert FNERR_INVALIDFILENAME. Ungültig ist aber fast zu viel gesagt, denn der Pfad enthielt an einer Stelle nur einfach 2 Backslashes statt einen, wie üblich.

Einfach nachzuvollziehen mit dem folgenden Snippet:

// Preset filename with a double backslash in the path:
// C:\TEMP\\Schrott.txt
CFileDialog dlg(TRUE,_T("txt"),_T("C:\\TEMP\\\\Schrott.txt"),
            OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
            _T("Text files|*.txt|All files|*.*||"));
INT_PTR iResult = dlg.DoModal();
DWORD dwLastError = GetLastError();
DWORD dwCommLastError = CommDlgExtendedError();

CString strResult;
strResult.Format(_T("Returncode %d, Lasterror 0x%08X, CommLastError 0x%08X"),
            iResult,dwLastError,dwCommLastError);
AfxMessageBox(strResult);

Eigentlich nur verwunderlich, denn der Name selbst mit doppelten Backslashes wird vom Dateisystem sonst überall akzeptiert. Man kann eine Datei mit dem Namen öffnen, lesen und schreiben. Nur CFileDialog mag ihn nicht. Oder besser der Standard-Common-File-Dialog mag ihn nicht.

Bleibt die Frage warum ich unter Vista den Fehler nicht bekam?

Nutzt man VS-2008 und lässt das Programm unter Vista laufen, dann ist auch alles wieder gut. Denn unter Vista benutzt Der CFileDialog ein neues Interface (Common Item Dialog) und nicht mehr den normalen Common-File-Dialog. Die neuen in die MFC gewrappten Dateidialoge von Vista können mit dieser Vorgabe umgehen.
Lässt man das gleiche Programm wieder unter XP SP2 laufen, bekommt man den entsprechenden Fehler wieder, da in diesem Fall wieder die Standard-Common-Dialoge verwendet werden.