Gesammeltes aus dem Leben eines "normalen" Programmierers… :-)
Jihad Dannawi kündigt in seinem Blog die Veröffentlichung von Visual Studio 2010 Beta 1 für MSDN Subscriber an:
http://blogs.msdn.com/dannawi/archive/2009/05/15/visual-studio-2010-beta-1-available-for-the-msdn-subscribers-on-monday-may-18th.aspx
Dito kann man es auf ZDNet lesen:
http://blogs.zdnet.com/microsoft/?p=2769
Ich freue mich schon drauf, ich hoffe es findet sich Zeit mal wirklich damit spielen zu können und um herauszufinden ob der Slogan „The new 10 is the next 6“ wirklich trägt… 😉
Jetzt sind es über 69.000, die diese Petition gezeichnet haben.
Als ich in den Nachrichten von dieser DNS-Sperrung gehört habe, hab ich gedacht ich spinne. Ich habe zu meiner Frau gesagt: Das ist eine der größten Bürgerveräppelungen der letzten Zeit. Trara wir sind die Kinderschützer und wer nicht mitmacht ist ein potentieller Bösewicht.
Ich werde hier wirklich veräppelt. Da wird ein großer Schlag angekündigt und jeder halbwegs bedarfte Anwender, der schonmal die TCP/IP Einstellungen seines OS gesehen hat, der weiß wie man einen anderen DNS Server einsetzt.
Ich habe diese Petition gezeichnet, nicht weil ich mit dem Text wirklich zu 100% einverstanden bin. Das mit der Zensur ist doch Quatsch. Gefährdung der Informationsfreiheit? Naja…
Für mich ist eher die Begründung schon Grund zum zeichnen. Ich muss doch wirklich nicht jedes sinnlose Handeln befürworten nur weil es wenigstens „etwas“ ist was man tut.
Für all das Geld, dass die Provider und die Regierung investiert haben hätte man vermutlich 3-5 neue Online-Fahnder einstellen können! Die hätten wahrscheinlich wirklich die Chance gehabt Kinder zu schützen und Täter zu entlarven. Diese Aktion ist eine typische sinnlose Verschwendung von Steuergeldern, von Ressourcen, von Zeit und Energie.
Für mich bleiben ein Haufen offener Fragen:
Warum können nicht Politiker wirklich mal Spezialisten konsultieren und auf die hören?
Es mag nicht „beliebt“ sein zuzugeben, dass man gegen Vieles machtlos ist, aber sinnloses Handeln kann dadurch nicht gerechtfertigt werden, dass man „irgend etwas“ macht? Vor allem wenn man noch andere Optionen hat, die nicht ganz so publikumswirksam sind. Oder verteilen wir in Zukunft gestärkte Hemden an unsere Polizisten als kugelsichere Westen? Oder Arnold Schwarzenegger wird jeden Feuerwehrmann in Kalifornien einen extra 10l Wassereimer finanzieren um der Waldbrände Herr zu werden…
Ich hoffe nicht, dass Arnold oder unser Innenminister meinen Blog lesen. Nicht das die noch auf dumme Gedanken kommen 😉
Immer wieder mal, taucht MFC Code auf und es wird CoInitializeEx verwendet.
Nicht unbedingt ein Fehler, aber ich denke man sollte auch hier die MFC-Art-und-Weise verwenden: AfxOleInit. Und man sollte sich klar sein, welche Apartment Modes man verwenden darf!
AfxOleInit selbst ist ein per Thread Wrapper für ::OleInitialize(NULL);.
Zudem sorgt AfxOleInit dafür, dass bei Beenden des Threads automatisch AfxOleTerm aufgerufen wird.
::OleInitialize(NULL) wiederum ist ein Wrapper für den Aufruf von CoInitializeEx im STA Kontext:
Siehe MSDN http://msdn.microsoft.com/en-us/library/ms690134(VS.85).aspx
OleInitialize calls CoInitializeEx internally to initialize the COM library on the current apartment. Because OLE operations are not thread-safe, OleInitialize specifies the concurrency model as single-thread apartment.
Die MFC benutzt und verlangt genau diesen STA Modus. Sofern man also nicht wirklich weiß was man mit CoInitializeEx macht, sollte man es in der MFC vermeiden. Zudem man sich eben auch nicht mehr um den Cleanup kümmern muss, da die MFC dies selber macht.
Siehe auch MSDN Doku zu AfxOleInit
http://msdn.microsoft.com/de-de/library/e91aseaz(VS.80).aspx
MFC applications must be initialized as single threaded apartment (STA). If you call CoInitializeEx in your InitInstance override, specify COINIT_APARTMENTTHREADED (rather than COINIT_MULTITHREADED). For more information, see PRB: MFC Application Stops Responding When You Initialize the Application as a Multithreaded Apartment (828643) at http://support.microsoft.com/default.aspx?scid=kb;en-us;828643.
Aber auch hier sei erwähnt, dass man sicherlich auch andere Apartment Modes verwenden kann. Allerdings muss man dann wirklich wissen was man macht und darf sich nicht auf die MFC Funktionen stützen. Für solche Fälle verwende ich hier komplett ATL in meinen MFC Programmen.
Man sollte aber in diesen Fällen wirklich wissen was man macht 😉
BTW: Automatisch aufgeräumt bei einem gestarteten Thread wird nur dann, wenn auch AfxBeginThread verwendet wird. Siehe auch: AfxBeginThread versus _beginthreadex
Wieder mal eine nette Falle: Implizite Konvertierungen und ein Refactoring-Versuch.
Folgende Methoden wurden in einer Klasse verwendet:
...
bool GetTableCoreData(long lIdAddrSet,
CAgvipTableCoreData &coreData,
bool bSilent=false);
bool GetTableCoreData(long lIdAddrSet, long lIdProject,
CAgvipTableCoreData &coreData,
bool bSilent=false);
bool GetTableCoreData(long lIdAddrSet,
CDataConnection &dataConnection,
CAgvipTableCoreData &coreData);
...
Die dritte Methode passte mir nicht von der Reihenfolge der Argumente. und ich änderte sie wie folgt um:
bool GetTableCoreData(long lIdAddrSet,
CAgvipTableCoreData &coreData,
CDataConnection &dataConnection);
Ich habe mich nun einfach darauf verlassen, dass der Compiler mir alle entsprechenden Code Stellen schon anmeckern wird, an denen hier was nicht passt. Da ich noch einiges anderes an der Klasse geändert hatte, dauerte es noch eine Weile bis ich den nächsten Build angeworfen habe, und ehrlich gesagt, habe ich das Refactoring dieser Funktion vergessen.
Typischer Fall von: Zu viel auf einmal & Der Compiler macht einfach nicht was ich will 😉
Was passierte? Nichts ❗
Ich bekam keine Fehlermeldung zu dieser Änderung, denn CDataConnection hat eine implizite Konvertierung auf bool. Die Folge war, dass die erste Signatur der Funktion auch dieser Folge von Argumenten entsprach.
bool GetTableCoreData(long lIdAddrSet,
CAgvipTableCoreData &coreData,
bool bSilent=false);
Logisch, dass diese Funktion natürlich eine anderes Verhalten hatte und hier nicht mehr das passierte was ich eigentlich wollte.
Dämlicherweise rutschte diese Änderung auch noch durch die Tests und eine ganze Funktionsgruppe unserer Software wurde lahmgelegt und so ausgeliefert… Ein Bug, dazu noch von der Kategorie vermeidbar.
Was lernen wir:
Ich nutze viel das MS-SQL Server Management Studio für MS-SQL 2005. Besonders um eben auch SQL-Statements zu testen und zu entwerfen.
Häufig lasse ich mir dazu einfach eine aktuelle Tabelle anzeigen. Mit Strg+3 kann man sich nun das SQL-Statement anzeigen lassen und es ändern. Also z.B. eine WHERE Bedingung hinzufügen.
Jeder der den Enterprise Manager gewohnt ist haut nun auf die F5-Taste, es passiert natürlich nichts 😮 . OK times are changing, wir benutzen also brav Strg+R um das neue Statement auszuführen.
OK nun klicken wir auf den Datenbanknamen und wählen hier im Kontextmenü Neue Abfrage aus. Ein bisschen SQL Statement schreiben und wir drücken Strg+R . 😮 Was denn nun? Wir bemühen also das entsprechende Menü und finden das hier der entsprechende Hotkey F5 ist.
Wer nun wieder mit MS-SQL Server 2008 arbeitet wird nun mit Strg+R kein Glück haben. Jetzt ist alles wieder gut und hier funktioniert nur noch F5. Jetzt ist dafür der Abfrage-Designer ist nun ein separater Dialog geworden, der das entsprechende Statement in das Abragefenster überträgt.
(Nachtrag 2009-05-06) Wenn man aus im Management Studio 2008 den Punkt Zeilen bearbeiten auswählt, hat man das selbe miese Verhalten wie im Management Stusio 2005. Man kommt nur nicht mehr so offensichtlich in diesen Bearbeitungsmodus und landet eher auf einer Abfrage, in der man dann aber das Ergebnis nicht bearbeiten kann.
Es gibt Momente in denen ich mich beherrschen muss nicht in die Tischplatte zu beißen… 😡
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 )
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 😉
In der englisch sprechenden Welt haben die MSDN Foren den NNTP Foren weitgehend den Rang abgelaufen.
Mit dem Launch von VS-2005 gab es auch den Versuch diese in Deutsch zu starten, was aber wirklich in die Hose ging, mangels Werbung, Angebot, Verweis und Akzeptanz der Pros und Regulars. Es wurden hier gerade einmal Untergruppen für die Visual-Express Versionen geschaffen. Dieses alte Forum ist noch zu finden unter:
http://forums.microsoft.com/msdn-de/default.aspx?siteid=9
Nicht mal 1000 Threads 6 Bereichen in mehr als 3 Jahren sind ein ziemlich müdes Ergebnis.
Nun wird ein zweiter Versuch gemacht mit einem weitaus größeren Angebot unter
http://social.msdn.microsoft.com/Forums/de-DE/categories/
Der Inhalt der alten Foren wurde auch in die neuen Foren Bereiche migriert.
Der Vorteil gegenüber dem alten System ist offensichtlich:
Nun bleibt abzuwarten ob diese Foren wirklich genutzt werden für C++ und Visual Studio allgemein. Oder ob die C++ Regulars lieber doch auf NNTP mit nntp://microsoft.public.de.vc verbleiben oder das bekannte Forum auf http://www.c-plusplus.de/forum nutzen. Über die Niveauunterschiede zwischen diesen beiden Foren brauche ich nichts zu sagen 😉 …
Anmerkung:
Ein Anachronismus ist sicherlich, dass man über die Community Links in der lokalen MSDN Installation oder auch über die Menüpunkte im Visual Studio (MSDN-Foren) sowohl bei der 2005er wie auch der 2008er Version, immer noch nur das alte Englische MSDN Forum erreicht, dass auch schon längst abgelöst wurde, und das man aktuell keine Möglichkeit hat aus VS, die deutschen Communities zu erreichen.
Ich frage mich manchmal warum die Community Aktivitäten von Microsoft, gerade im nicht Englisch sprechenden Bereich, selten einmal koordiniert erscheinen. Es kommt mir so vor, als ob die Betreuung dieser Bereiche einfach jemanden aufgedrückt wird, der genug Anderes zu tun hat und diese Bereiche eher nebenbei betreuen „muss“… und auf Befehl von irgendwo oben wird dann eben mal mit Hauruck „Irgendwas“ gemacht, weil man muss ja mal was machen…
Manchmal kann man den Standby Mode wirklich nicht gebrauchen. Besonders, wenn man ein Programm hat, dass evtl. viel im Hintergrund mit einer Datenbankverbindung macht.
Wie macht man es unter Windows Vista richtig, denn BROADCAST_QUERY_DENY bei einem PBT_APMQUERYSUSPEND oder PBT_APMQUERYSUSPENDFAILED zurückzugeben funktioniert nicht.
Man muss SetThreadExecutionState verwenden!
Äußerst dumm nur, dass man dies auch wirklich für Windows Vista und Windows 7 berücksichtigen muss. Ich hatte natürlich für Windows 2000 und XP entsprechenden Code vorgesehen, die den Standby verhindern, aber wie schon erwähnt, das geht eben unter Vista nicht mehr.
Es gibt Inkompatibilitäten zwischen des OSen, die man wirklich explizit behandeln muss. Es lohnt sich ein Blick in die Dokus, den ich selber oft genug nicht mache… 😉
// Every 30 secs we disallow the standby and hibernate!
// We have to use ES_AWAYMODE_REQUIRED on Vista and Windows Server 2008
// If we allow standby and hibernation we get problems with the DB connection.
DWORD dwAwaymodeRequired = 0;
OSVERSIONINFO os;
::ZeroMemory(&os,sizeof(os));
os.dwOSVersionInfoSize = sizeof(os);
if (::GetVersionEx(&os) && os.dwMajorVersion>=6)
dwAwaymodeRequired = ES_AWAYMODE_REQUIRED;
VERIFY(::SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED |
dwAwaymodeRequired));
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:
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:
Macht man das ganze unter Vista, dann liefert LVM_GETSUBITEMRECT /CListCtrl::GetSubbItemRect ein RECT / CRect mit der Weite der Symbole immer dann wenn:
Das heißt in dem Fall
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.
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“:
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: