Schlagwort: C++

MFC Updates for Visual Studio 2008 and Beyond: MFCnext

Was ich hier schreibe ist an sich viel zu viel für einen einzigen Blog Artikel, deshalb behalte ich mir hier nur eine kurze Zusammenfassung vor. Kommentieren und diskutieren werde ich dies noch in den nächsten Wochen.

Was ❓
Heute in den C++ Sessions der TechEd 2007 in Barcelona wurde ein Geheimnis gelüftet. Das war uns MVPs schon etwas länger bekannt aber leider war es uns bis heute durch NDA (non-disclosure aggreement) untersagt davon zu berichten.
Microsoft wird der MFC einen neuen gewaltigen Schub geben und seit Jahren die ersten wirklich gravierenden Erweiterungen verpassen. Das Ganze wird unter dem Namen MFCnext laufen.

In diesem Bog will ich nur summarisch aufzählen was alles an Neuem kommen wird:

  • Office 2007 UI Stil. Ribbons und alles was dazu gehört
  • Tabbed MDI
  • Integration neuer Controls (Advanced button, Shell tree and list, Mask edit, Property list)
  • Erweiterter Applikations Assistent
  • Rückwärts kompatibel bis Windows 2000
  • Docking wie wir es von Visual Studio her kennen
  • Visual Styles (Skins)
  • Die Standard Template Library wird um TR1 erweitert (tr1::shared_ptr, tr1:: mem_fn, tr1:: bind, tr1::regex, tr1::tuple, tr1::array, unordered containers hash-based, tr1::type_traits)
  • Microsoft bekennt sich klar und offen zur weiteren Entwicklung und Unterstützung der nativen C++ Programmierung.
  • und vieles andere mehr…

Die MFC wird sich in Anzahl der Klassen und Größe verdoppeln.

Wann kommt das ❓
Das Ganze wird bereits im März 2008 nachgeliefert, in einem Update für VS-2008. Ein Release Kandidat (RC) wird bereits im Dezember 2007 zur Verfügung stehen.  So die bisherige Planung.

Die MFC ist tot… lange lebe MFCnext 😀

Weitere Infos:
Auch in Deutschland bei dieser Veranstaltung werden die Vortargenden aus Barcelona zu sehen und hören sein:
München 15.11.2007: Visual C++ 2008 und danach, Ask the Experts

Noch mehr Infos gibt es auch in dem Blog von Jochen Kalmbach, der live aus Barcelona von der TechEd 2007 berichtet.

Mal ganz schnell sich selbst reingelegt mit Excel und CRecordset::optimizeBulkAdd

Um eine größere Datenmenge in Excel über eine ODBC Verbindung zu erzeugen habe ich einen entsprechenden Recordset geöffnet und Daten massenweise hineingepumpt. Die Tabelle (das Worksheet), das erzeugt wurde enthielt Spalten mit Text-, Numerischen-, und Zeitdaten. Einige der Daten sollten wurden mit NULL Werten erzeugt werden.

Entsprechend den Tipps in der Doku habe ich die zusätzliche Option CRecordset::optimizeBulkAdd zu CRecordset::appendOnly verwendet um das zu beschleunigen.

m_recordSet.Open(CRecordset::snapshot,
                NULL,
                CRecordset::appendOnly|CRecordset::optimizeBulkAdd);

Laut der Doku sollte das erste Statement entsprechend für alle weiteren Operationen, den Dirty-Status setzten. Fein (dachte ich), alle Daten des Recordsets werden gesetzt, entweder auf den entsprechenden Wert oder NULL.

Alle Tests waren „erstmal“ positiv. Die Daten wurden in guter Geschwindigkeit erzeugt.
Leider stellten Kunden dann fest (allerdings Wochen später), dass unter bestimmten Umständen ganze Spalten leer waren. Sobald in der ersten Zeile einmal in einer Spalte NULL ausgegeben wurde, dann wurde auch in allen folgenden Spalten kein Wert eingetragen. Das Ganze, obwohl die Daten korrekt gebunden und als dirty markiert wurden. An das Open Statement dachte ich nicht…

Nach langem Testen nahm ich schon an, einen Bug in dem ODBC Treiber gefunden zu haben. Stutzig wurde ich aber, dass alles prima klappte, wenn ich pure SQL INSERT-Statements mit ExecuteSQL  direkt auslöste, ohne den Recordset zu bemühen. Was nun?

Relativ ratlos wollte ich schon einen Supportfall bei Microsoft öffnen, bis ich den Code noch einmal Schritt für Schritt durchsah und wieder über das das Open Statement stolperte.

Bingo: Sobald ich dieses Flag entfernte arbeitete alles korrekt. Nach meinem Verständnis müsste auch ein NULL Wert ein Wert sei, der gültig ist, solange ich alle Spalten beim ersten INSERT/AddNew angebe. Ich nahm an, dass auch ein Einfügen eines NULL Wertes ein „Dirty“ für die entsprechende Spalte auslöst. Das ist aber nicht so.

Wird – zumindest beim ODBC Treiber für Excel – in dem ersten INSERT eines Datensatzes ein NULL Wert ausgegeben , dann werden auch keine Daten für alle nachfolgenden Zeilen eingefügt. Und das NULL eingefügt wird, geschieht ganz schnell, wenn z.B. ein leeres Textfeld (Länge 0) ausgegeben werden soll. Ob dies auch für Access oder andere Treiber gilt habe ich noch nicht ausprobiert.

Schnelle binäre Algorithmen

Manchmal tauchen in Foren richtig nette Sachen, die einen in Erstaunen setzen, wie schnell und einfach manches zu lösen ist. (siehe Thread)
Zwei interessante Fragen, die mich auch schon öfter beschäftigt haben sind hier mal erwähnt und als C++ Code wiedergegeben. Bisher habe ich diese immer mit einer entsprechenden Schleife und Shift-Operatoren gelöst.

1. Wie kann man schnell prüfen ob ein Integer eine 2er Potenz ist?

Der Algorithmus ist so verblüffend einfach, dass man sich fragen muss, warum man noch nicht von selbst drauf gekommen ist:

bool IsPowerOf2(int n) 
{ 
 return (n & (n - 1))==0; 
}

Tricky: Wenn mehr als zwei Bits gesetzt sind, bleibt bei der gegebenen Arithmetik mindestens das höchste Bit stehen.

❗ Nach diesem Algorithmus ist 0 übrigens auch eine Power of 2!

2. Wie findet man die nächste 2er Potenz einer gegebenen Zahl?

Diese Frage stellt sich für mich immer wieder, wenn ich binäre Suchen durchführe.
Auch hier gibt es eine statische Lösung, die ich hier mal wiedergebe und die sowohl für 32bit als auch für 64bit funktioniert und direkt in entsprechende Assembler Befehle umgesetzt wird.
Der Code vermeidet einen 32bit shift, da das Ergebnis in einem 32bit C++ Compiler undefiniert ist (Warning C4293).

int GetNextPowerOf2(int n) 
{ 
 // Code works for 32bit and 64bit 
 ­­­­-­-n;    
 n |= n >> 1; 
 n |= n >> 2; 
 n |= n >> 4; 
 n |= n >> 8; 
 n |= n >> 16; // Sufficient for 32bit 
 n |= n >> 16; // for a 64bit System we need a new 32bit shift (n>>32) 
 n |= n >> 16; // but this operation is undefined on a 32bit system 
               // so we use 2 16bit shifts. (C4293) 
 return n+1; 
}

Oft genug wird das höchste gesetzte Bit gesucht. In diesem Fall einfach den Startwert oder das Ergebnis um eine Bitposition shiften.

Tricky: Das höchste Bit wird nach der Subtraktion einfach auf alle niederen Bits übertragen.

❗ Auch hier ist das Verhalten bei 0 eigentümlich. Die nächste 2er Potenz auf 0 ist mit diesem Algorithmus 0!

Die entsprechenden Algorithmen sind hier auf dieser Seite beschrieben:
http://en.wikipedia.org/wiki/Power_of_two#Fast_algorithm_to_check_if_a_number_is_a_power_of_two

Warum eigentlich CallWindowProc aufrufen, wenn man einen Zeiger auf die alte WndProc hat?

Wenn man mit GetWindowLong(Ptr) und GWL_WNDPROC die Adresse einer Fenster Prozedur ermittelt hat, warum muss man eigentlich CallWindowProc aufrufen und nutzt nicht direkt den Zeiger? Geht das denn überhaupt? 😕

❗ Nein es geht nicht und man sollte es gar nicht versuchen ❗

In Win16 ging das noch. Aber das was durch GWL_WNDPROC geliefert wird ist seit Einführung von Win32 nicht unbedingt ein Funktionszeiger mehr.  Oft ist es eine Struktur.
Warum? Das ganze wurde gemacht um Unicode Kompatibilität zu erreichen.
Fenster sind nicht nur Thread afin, nein, sie sind auch Unicode bzw. MBCS afin (wenn man das so sagen kann). Je nachdem ob es eben mit CreateWindow(Ex)A oder CreateWindow(Ex)W erzeugt wurde.

Wenn also ein Unicode Fenster von einer Nicht-Unicode Fenster-Prozedur gesubclassed wird (oder umgekehrt), dann muss hier eine Konvertierung stattfinden. Seit dem wir Themed Style mit XP bekommen haben, tritt dies übrigens häufig auf. Denn die Fenster im XP-Stil werden meistens intern als Unicode Fenster verwaltet oder angelegt.
Für diese Konvertierungsarbeit wird eine Struktur angelegt und diese Struktur wird dann in GWL_WNDPROC eingetragen. Dann haben wir eben keinen Funktionszeiger mehr, sondern eher ein Handle. Und nur CallWindowProc weiß wie man eben damit umzugehen hat…

Details hier in dem Artikel Safe Subclassing in Win32

Gibt es einen Unterschied zwischen HMODULE und HINSTANCE?

Ja! Wenn man noch Windows 16bit programmiert. 😉

Nein! Wenn es sich um Win32 dreht.

In Kurzfassung:
❗ Seit Win32 ist HMODULE/HINSTANCE nichts anderes als die Ladeadresse des Modules, egal ob es sich hier um eine EXE oder DLL handelt.
HMODULE und HINSTANCE sind austauschbar in jeder Beziehung.

Wer mehr darüber lesen will findet bei The Old New Thing, diesen Artikel der den historischen Aspekt erläutert.

Wie eine Gruppe von Radio-Buttons ein Programm aufhängen können

Auto-Radiobuttons (BS_AUTORADIO) sind als Standard in fast jedem Dialog zu finden. Das diese netten kleinen Buttons ein Programm dazubringen können sich aufzuhängen, ohne das unbedingt eigener Code im Spiel ist, kann man sich kaum vorstellen.
Aber es kann passieren.

Ein Regular in der Gruppe nntp://microsoft.public.de.vc berichtete dieses Problem mehrfach in der Gruppe. Letzten Endes trugen aber alle Ideen und Vorschläge zu keiner Lösung bei.

In einem Thread wurde dann ein Beispielprogramm veröffentlicht, bei dem mit einem simplen Klick auf einen Radiobutton das Programm in einer Endlosschleife gerät und sich aufhängt.

Die Ursache ist trivial. Eine Gruppe von Auto-Radio Buttons war nicht durch ein Control mit dem Stil WS_GROUP abgeschlossen worden. Solch einen Design Fehler im Dialog hat schon jeder mal gemacht und viele werden die folgende Ausgabe im Debug Fenster kennen: „Warning: skipping non-radio button in group.“

In diesem Fall kam nach der Gruppe Radio Buttons ein Tab-Control, dass den Stil WS_EX_CONTROLPARENT hat. Dieser Stil erlaubt es Dialoge und Controls zu schachteln. Gleichfalls führt dieser Stil dazu, das versucht wird die Gruppe von Radio-Buttons in den untergeordneten Feldern weiter zu führen. Leider waren in den entsprechenden Fenstern auch keine Controls mehr mit dem Stil WS_GROUP und irgendwie hat sich die Windows UI-API dann letzten Endes aufgehängt.

Behoben werden konnte dieser Stil einfach;

  • Entweder man führt ein (evtl. sogar unsichtbares) Static Control ein, direkt nach der Gruppe. Static-Controls werden automatisch mit dem WS_GROUP Stil versehen.
  • Oder man änderte die Z-Order, so dass auf die Radio-Button Gruppe ein anderes Control mit WS_GROUP Eigenschaften folgt.
  • Oder eines der Controls im Unterdialog hat den WS_GROUP Stil, was aber oft genug nicht dem eigentlich gewollten Design entspricht, dass sich die Gruppe in den Unterdialog fortsetzt.

Auch so simplen Warnungen in der Debugausgabe wie „Warning: skipping non-radio button in group.“ sollte man gezielt nachgehen. Manchmal haben heftige Probleme trivialste Ursachen ❗

Anmerkung: Das Beispielprogramm ist zwar noch VC6, aber das Problem liegt im Design der geschachtelten Fenster und der nicht abgeschlossenen Radio-Button Gruppe.

Die Cx2y Falle…

In einem Programm habe ich diese unscheinbare Schleife für eine spezielle Analyse im Debug-Mode eingebaut.

for (POSITION pos= m_aBind.GetHeadPosition(); pos; )
{ 
 S_BIND& b= m_aBind.GetNext(pos);
 TRACE(__FUNCTION__ “  %-32s %2d\n“,
  CT2A(b.sName.GetString()),
  b.GetStatus());
}

Sieht auf den ersten Blick OK aus.
Auf den zweiten Blick wundert einen evtl. die Nutzung von CT2A. Warum nehme ich nicht einfach den Zeiger von GetString wie er ist? Es ist ja ein PCTSTR! Begründung:

  1. Das Projekt ist ein Unicode Projekt. 
  2. CT2A verwende ich hier, weil die TRACE Funktion in dieser Schreibweise nur MBCS Strings verwendet. D.h. %s erwartet einen Zeiger auf einen MBCS String.
  3. Die _T Schreibweise für die Ausgabemaske ist hier nicht geeignet, weil ich gerne den Funktionsnamen auch mit ausgegeben hätte. Und __FUNCTION__ ist nun mal eine normale String-Konstante, und kein wchar_t-String.
  4. T2A verwende ich nicht, weil dies in einer Schleife tödlich ist, weil der Stack immer weiter anwächst.

OK! Soweit dazu, warum der Code aussieht wie er aussieht.

❗ Nur… es kommt nur Schrott dabei heraus!
Die Ausgabe zeigt brav, den Text, den ich haben möchte, nur die Zahlenwerte stimmen in keiner Weise mit den Rückgabewerten von GetStatus überein! Warum? ❓

Was ist passiert? Der Debugger gibt schnell Auskunft:
CT2W erzeugt ein Objekt vom Typ CW2AEX!!! Dieses Objekt ist aber größer als ein PCSTR Zeiger. Dieses Objekt umfasst bei meinen Projekteinstellungen 4 Bytes für einen Zeiger plus einen char-Array der Größe 128. TRACE hätte aber gerne einen 4-Byte Zeiger auf dem Stack und danach für die Ausgabe einen Integer.
Ausgegeben, werden also die 4 ersten Bytes des Puffers von CW2AEX und nicht die gewünschten numerischen Werte für GetStatus!

Das ist übrigens die selbe Falle in die man tritt, wenn man CString direkt ohne CString::GetString in printf/TRACE und Konsorten verwendet. Nur hat man hier das Glück, dass ein CString exakt 4 Bytes groß ist und genau aus einem Zeiger auf einen PTSTR besteht.

Wie macht man es richtig?
Genau… man führt den entsprechenden cast ein. Der cast benutzt nun den cast-Operator der Klasse CW2AEX, und der liefert uns den Zeiger den wir wollten.

for (POSITION pos= m_aBind.GetHeadPosition(); pos; )
{
 S_BIND& b= m_aBind.GetNext(pos);
 TRACE(__FUNCTION__ “ %-32s %2d\n“,
  static_cast<PCSTR>(CT2A(b.sName.GetString())),
  b.GetStatus());
}

Amerkungen:

  • Ich brauche wahrscheinlich nicht zu erwähnen, dass ähnliche Probleme mit CA2W, CA2T etc. auch auftauchen können.
  • An den meisten Stellen an denen, wir diese Konvertierungen, wie z.B. CT2A verwenden wird auch direkt ein PCTSTR erwartet, oder eben ein Zeiger auf den entsprechend konvertieren String. Dadurch wird implizit der Konvertierungs-Operator der Klasse aufgerufen und damit funktioniert ales wie es soll.
  • Auch wenn das Projekt ein MBCS Projekt gewesen wäre, hätte es die selben Probleme verursacht. Denn in diesem Fall wird aus CT2A eine Objekt der Klasse CA2AEX. Im Gegensatz dazu würde T2A einfach zu ener Noop.

Das verschollene Scribble Tutorial…

Immer wieder merke ich, dass man bei vielen Anfragen in den Foren auf den Klassiker verweisen müsste:
Das Scribble Tutorial.

Dieses Tutorial ist offiziell über die MSDN Suche im Internet nicht mehr zu finden. Egal wie man auf den MS-Seiten sucht. Interessant ist, dass es noch genug KB-Artikel gibt die auf dieses Tutorial verweisen. Der Sample Code ist noch vorhanden. Nur das Tutorial ist nicht einfach zu finden.

Aber es existiert noch in einem Ast der MSDN, die die VC++ 6.0 Dokumentation beinhaltet.:
http://msdn2.microsoft.com/en-us/library/aa716528(VS.60).aspx

Leider ist dieser Ast mit der globalen Suchfunktion nicht erreichbar und auch nicht entsprechend indiziert.
Meiner Meinung nach, hätte dieses Tutorial schon längst angepasst werden müssen, weil sich die Wizards komplett seit VS.NET 2002 geändert haben.

BTW: Leider befürchte ich, dass auch dieser VC++ 6.0 Ast der MSDN irgendwann verschwinden wird.

SetFocus versus WM_NEXTDLGCTL

Die meisten Entwickler verwenden SetFocus um in einem Dialog gezielt den Eingabefokus zu versetzen. Aber es gibt ein Problem, dem SetFocus nicht gerecht wird: der Default Button.
Der Default Button wird durch WM_SETDEFID bzw. CDialog::SetDefID gesetzt. SetFocus berücksicht das interne Konzept des Default Buttons nicht.

Wenn man mit der Tab-Taste durch einen Dialog springt und einen Button erwischt, dann wird dieser automatisch zum Default Button. Normalerweise ist das der OK-Schalter, er verliert dann den dicken Rahmen. Drückt man die Eingabe-Taste, dann wird nun der neue Schalter ausgelöst und nicht der OK-Schalter.
Landet der Fokus von einem Button dann bei einem Edit Control, dann wird der OK-Schalter wieder der Default Button und man kann mit der Eingabe-Taste den Dialog beenden.

Wenn nun SetFocus verwendet wird durch eine interne Funktion, dann wird dieser Mechanismus des Dialoges umgangen. Der Default-Button wird evtl. nicht korrekt gesetzt. Es kann sogar soweit kommen, dass es zwei Default-Schalter oder gar keinen mehr gibt. SetFocus führt immer zu Problemen wenn das neue Control oder das bisherige Control, welches den Fokus hatte, ein Button ist. Nur wenn beide Controls keine Button sind kann SetFocus gefahrlos verwendet werden.

Korrekt funktioniert das Ganze nur, wenn statt SetFocus, WM_NEXTDLGCTL verwendet wird, oder die entsprechenden MFC Funktionen, CDialog::NextDlgCtrl bzw. CDialog::GotoDlgCtrl verwendet werden.
Die Nachricht WM_NEXTDLGCTL wird auch intern durch die DefDialogProc behandelt und normalerweise durch IsDialogMessage erzeugt.
Gefahrlos ist auch die Verwendung von SetFocus in WM_INITDIALOG bzw. CDialog::OnInitDialog Handlern, die dann normalerweise mit FALSE, verlassen werden. Nach dieser Funktion sorgt der Dialog Handler, für die korrekte Behandlung der Default Buttons.

Fazit: Man sollte also innerhalb von Dialogen ganz auf SetFocus verzichten sondern nur WM_NEXTDLGCTL  bzw.  CDialog::NextDlgCtrl und CDialog::GotoDlgCtrl verwenden. Konsequenterweise sollte man dann auch in OnInitDialog Handlern auf SetFocus verzichten. ❗

Besonderheiten bei der Ausgabe über Excel via ODBC

Man sollte tunlichst darauf achten, dass bei Excel Export über ODBC alle Spalten mit einem möglichst exakten Datentyp erzeugt werden. D.h. der Faulheit halber sollte man nicht jede Spalte mit dem Typ TEXT erzeugen, sondern eben DOUBLE, NUMERIC, BIT, DATETIME etc. verwenden, die Excel auch unterstützt. In diesem Fall werden nur die TEXT-Daten mit einem Apostroph versehen. (siehe dieser Blogbeitrag)

Lästig ist, dass Excel es nicht schafft DATETIME, DATE und TIME Spalten standardmäßig auch korrekt anzuzeigen. DATETIME-Spalten werden zwar korrekt mit Datum und Uhrzeit befüllt. Das Anzeigeformat wird aber so dämlich gewählt, dass nur das Datum sichtbar ist. Für DATE-Spalten geht das in Ordnung. Bei TIME-Spalten wird sogar noch einfach das Tagesdatum „hinzugedacht“, obwohl nur der Zeitwert übertragen wurde. D.h. man sieht ein Tagesdatum aber nicht die Zeit. Die Zeit wird nur sichtbar beim Ändern des Formtes der Zellen, oder wenn man die Daten einzeln anklickt und in der Bearbeitungsleiste betrachtet.

Trickreich ist auch die Ausgabe in ein DATETIME Feld, wenn man ein Textfeld bindet. In diesem Fall muss zwingend das Format JJJJ-MM-TT für die Ausgabe verwendet werden.

Ein weitere Trick besteht darin, die Spalten zusätzlich mit der Option NULL anzulegen:
CREATE TABLE [Data] ([Field1] TEXT NULL, [Field2] DOUBLE NULL)
andernfalls braucht man sich nicht wundern, wenn es eine Exception gibt beim Speichern eines leeren Strings.