kürzlich fiel mir ein überraschender Effekt im Zusammenhang mit WinForms TreeViews und drag and drop auf. Fall man im MouseDown-Event eine DragDrop-Operation mit der Methode DoDragDrop() startet, wird der selektierte Knoten nicht auf den angeklickten Knoten gesetzt.

In folgendem Beispiel wurde der Knoten “BasicActivities” angeklickt und damit zum selected node. Anschließend wurde der Knoten ActivityFinalNode angeklickt. Der Focus-ähnliche Rahmen um den Knoten “BasicActivities” blieb aber erhalten:

Das hat zur Konsequenz, dass der zuvor selektierte Knoten “BasicActivities” nach einer anschließenden Mousebewegung ohne click wieder selektiert wird.

Dieses Verhalten tritt nicht auf, wenn der Aufruf der Methode DoDragDrop() unterbleibt.

Wenn man den Knoten im MouseDown-Event explizit selektiert (wie hier beschrieben), tritt dieser Effekt nicht auf und das TreeView verhält sich wie gewohnt.

theTreeView.SelectedNode = nodeAt;
DoDragDrop(nodeAt.TheClass, DragDropEffects.Copy);

Viele Grüße,
Andreas

Technorati Tags: WinForms, Drag and Drop

Microsoft hat mit der Einführung des .NET-Frameworks auch C++-Erweiterungen (C++/CLI) definiert, mit denen vorhandener C++ source code für .NET-Anwendungen verfügbar gemacht werden kann.

Die Intention dabei war die Steigerung der Akzeptanz des .NET-Frameworks, da es relativ einfach gemacht wird, bereits vorhandenen C++ code in .NET-Anwendungen zu integrieren. Meiner persönlichen Erfahrung nach geht das sehr gut, d.h. es ist ziemlich einfach vorhanden C++ code mit C++/CLI .NET-tauglich zu machen und die entstandenen Assemblys haben keine nennenswerten Einschränkungen (abgesehen davon, dass sie nur für die Plattform geeignet sind, für die der native code kompiliert wurde).

Der übliche Weg besteht darin eine neue Assembly zu erstellen, die C++/CLI Klassen (und ggf. native Klassen) enthält. Diese Klassen rufen dann den eigentlichen legacy code, typischerweise in bereits vorhandenen Libraries/DLLs.

Folgende Frage stellt sich bei der Erstellung eines Managed C++ Wrappers um vorhanden C++ code schnell:

Wie kann ich innerhalb des .NET-Wrappers native Datenstrukturen zwischen managed Klassen austauschen?

Dies ist grundsätzlich nicht ohne weiteres möglich, da in der öffentlichen Schnittstelle nur CLR-kompatible Datentypen verwendet werden dürfen (ansonsten könnten nicht alle Elemente der Schnittstelle von anderen .NET kompatiblen Komponenten konsumiert werden).

Es ist allerdings möglich, private Methoden zu definieren, die nicht CLR-konforme Datentypen konsumieren oder zurückgeben dürfen. Damit solche Methoden von anderen Klassen in der C++/CLI Wrapper-Assembly gerufen werden dürfen, müsste man alle diese Klassen als friend definieren, was eine etwas unbefriedigende Lösung ist.

Diese Überlegung führt aber zur optimalen Lösung: die Deklaration der entsprechenden Methoden als public private. public private ist in C++/CLI die Entsprechung zu internal in C# und bedeutet “sichtbar innerhalb der Assembly”.
Da die entsprechenden Methoden nur von den C++-Klassen innerhalb der Wrapper-Assembly gerufen werden, gibt es keinen Grund sie zu verbieten (was der Compiler dann auch nicht macht).

Viele Grüße,
Andreas

Technorati Tags: .NET, Managed C++

die  “Beruf und Karriere”-Beilage der Süddeutschen Zeitung vom 1./2.08.09 enthielt einen interssanten Artikel mit dem Titel “Uni-Abgänger verdienen mehr als FH-Absolventen”.

Darin wurden die Ergebnisse einer Befragung von mehr 5000 Absolventen des Jahrgangs 1997 veröffentlicht. Im Durchschnitt verdienten Uni-Abgänger 10 Jahre nach Ende ihres Studiums 64.300,00 EUR während FH-Absolventen 59.400,00 EUR verdienten.

Soweit entspricht das etwa dem was man erwarten würde.

Überraschenderweise scheint das für die Informatik nicht zu gelten, hier verdienten Uni-Abgänger im Schnitt 70.800,00 EUR und FH-Abgänger 77.300,00 EUR. Das sind rund 10% mehr!

Ich selbst habe ebenfalls trotz allgemeiner Hochschulreife an der FH studiert und war mit dieser Entscheidung sehr zufrieden. Ich habe in den beiden Praktikumsemestern in zwei verschiedenen Unternehmen gearbeitet und auch die Diplomarbeit in einem (dritten) Unternehmen geschrieben. Dabei habe ich sehr viel gelernt, wertvolle Kontakte geknüpft und auch meine erste Stelle nach dem Studium gefunden.

Interessehalber noch die Ergebnisse für die anderen Fächer (erstgenannt die Gehälter der Uni-Absolventen):

Bauingenieur: 56.100,00 gegenüber 49.700,00
Elektrotechnik: 70.900,00 gegenüber 64.200,00
Maschinenbau: 76.200,00 gegenüber 62.900,00

Auffällig ist auch der große Abstand bei den Maschinenbauern.

Viele Grüße,
Andreas

Technorati Tags: Gehalt, Uni, FH, Informatik, Elektrotechnik, Maschinenbau

es gibt eine klare Empfehlung für die tägliche Arbeit auf einem Computer mit Windows XP ein Konto mit eingeschränkten Rechten zu verwenden. Der Hauptgrund ist die damit stark reduzierte Wahrscheinlichkeit einem Virus oder anderer Malware zum Opfer zu fallen.

Für Entwickler gibt es noch einen weiteren, wesentlichen Grund für die Verwendung eines Kontos mit eingeschränkten Rechten: sie testen damit automatisch, ob die entwickelte Software auch mit eingeschränkten Rechten funktioniert – was gut geschriebene Software machen sollte.

Dummerweise bekommt man bei diesem vorbildlichen Vorgehen ein Problem, wenn man eine ATL COM Komponente erzeugt. Für diesen Projekttyp aktiviert Visual Studio die Linker Option “Ausgabe registrieren”.
Damit wird nach erfolgreichem Linken der Komponente regsvr32 /s aufgerufen, um die frisch erstellte Library zu registrieren. Dieser Aufruf scheitert bei Verwendung eines Kontos mit eingeschränkten Rechten da die Registrierung von COM-Komponenten Administrator-Rechte erfordert:


Project : error PRJ0050: Fehler beim Registrieren der Ausgabe. Vergewissern Sie sich, dass Sie über die entsprechenden Berechtigungen zum Ändern der Registrierung verfügen.


Für solche Fälle ist die Verwendung des Kommandos runas eine naheliegende Option aber leider hat man auf die von Visual Studio erzeugte Programmzeile für den Aufruf von regsvr32 keinen Einfluss, diese ist nämlich Teil der Visual Studio Programmierschnittstelle und damit nicht direkt zugänglich.

Eine einfache Lösung besteht darin, die oben genannte Linker-Option “Ausgabe registrieren” zu deaktivieren und ein eigenes “Postbuildereigenis” für das Projekt zu definieren. Dieses könnte z.B. so aussehen:


runas /user:administrator /savecred "regsvr32 /s $(TargetPath)"


Damit das funktioniert muss man einmal den Befehl in einem Kommandofenster eingeben und dann nach der Aufforderung das Administrator-Password eingeben. Bei jedem weiteren Aufruf mit /savecred wird dann das zuletzt verwendete Passwort automatisch verwendet. Damit ist vermieden, dass das Administrator-Password im Klartext in einer Visual Studio Projektdatei steht, was eine erhebliche Sicherheitslücke darstellen würde.

Falls man das gemerkte Passwort später wieder löschen möchte: Systemsteuerung/Benutzerkonten/Eigene Netzwerkkennwörter verwalten.

Viele Grüße,
Andreas

Technorati Tags: Visual Studio, COM, ATL, Registry, Eingeschränkter Benutzer

nachdem mich das Finanzamt an die Abgabe der Steuererklärung erinnert hat, habe ich mein Wiso Sparbuch 2009 gestartet und natürlich die schöne Suche nach Aktualisierungen gestartet.
Nach kurzer Zeit erscheint die Meldung:

Sie haben JavaScript deaktiviert. Damit sind wichtige Funktionen dieses Programms nicht verfügbar.
Weitere Informationen zu JavaScript und wie Sie JavaScript aktivieren finden Sie hier.

Bitte aktivieren Sie JavaScript und starten das Programm dann erneut.

Was soll denn bitte diese Meldung? Ich habe eine FAT Client Anwendung zur Abgabe meiner Steuererklärung gestartet. Wo und wie soll ich denn nun JavaScript aktivieren?
(Wer nun denkt, in obiger Meldung wäre “hier” ein Link, den muss ich enttäuschen)

Hallo Ihr Buhl-Programmierer! Schon mal daran gedacht, dass Ihre Software vielleicht von Personen eingesetzt wird, die mit einer solchen Meldung nicht zurechtkommen? Oder von Personen, die keine Lust haben ihren PC in einen Bot voller Malware zu transformieren?

Um dem Ganzen noch die Krone aufzusetzen, startet beim Klick auf den Link “Support” in obigem Dialog der Internet Explorer, obwohl ich den Firefox als Standardbrowser konfiguriert habe. Und die Suche in der Hilfe geht nicht ohne…JavaScript.

Aber als Entwickler einer Software zur Abgabe von optional verschlüsselten Steuererklärungen hat man mit Themen wie Vertraulichkeit und Sicherheit natürlich überhaupt nichts zu tun.

Unnötig zu erwähnen, dass bis zur letztjährigen Ausgabe der Update-Mechanismus von Wiso-Sparbuch auch ohne JavaScript funktioniert hat.

Ach und noch etwas, Windows 7 kommt in Europa ohne Browser auf den Markt…

Viele Grüße,
Andreas

Technorati Tags: JavaScript, sichere Software

manchmal möchte man wissen, ob ein bestimmter Benutzer bestimmte Rechte (z.B. Schreibrechte) für eine bestimmte Datei besitzt. Wie sich herausstellt, ist diese Anforderung alles andere als leicht umzusetzen, weil dabei viele verschiedene Aspekte eine Rolle spielen. Die Vorgehensweise sieht prinzipiell so aus:

• Abfragen der Access Control Listen für die Datei
• Itererieren über alle Einträge und prüfen ob man für die Kennung oder die Gruppe des gewünschten Benutzers Einträge findet
• Dabei die Präzedenz der Einträge beachten (explizite kommen vor vererbten Regeln, “Deny”-Regeln kommen for “Allow”-Regeln)

Den nicht unerheblichen Code hat dankenswerterweise Bruce Hatt in einem Artikel auf CodeProject.com veröffentlicht.

Man sollte bedenken, dass die Möglichkeit in eine Datei zu schreiben zusätzlich durch das “ReadOnly-flag” und die .NET Code Access Security eingeschränkt sein könnte. Beides wird in dieser Klasse nicht berücksichtigt.

Die Prüfung auf das ReadOnly-flag könnte man so schreiben:

FileAttributes attrs = File.GetAttributes(fileName);
 
if ((attrs & FileAttributes.ReadOnly) != 0)
{
    readOnly = true;
}

Und für die Prüfung im Rahmen der CAS könnte man folgenden Code verwenden:

FileIOPermission fp = new FileIOPermission(FileIOPermissionAccess.Write, fileName);
try
{
    fp.Demand();
}
 
catch (SecurityException)
{
    readOnly = true;
}

Wenn es nur um die Prüfung auf Schreibrechte geht, hört man oft den Vorschlag, einfach den Schreibvorgang auszuführen und ggf. die geworfene Exception zu fangen. Dieser Vorschlag ist aber nicht immer geeignet. In meinem Fall war es so, dass ich an einer Anwendung arbeite, in der Dateien editiert werden können. Falls Dateien nicht geschrieben werden können, soll dies visualisiert werden. Man möchte aber vermeiden, dazu bei jedem Start der Anwendung die zu editierenden Texte zu speichern, da damit der Timestamp verändert wäre, obwohl der Benutzer die Datei gar nicht geändert hat und auch nicht speichern wollte.

Viele Grüße,
Andreas

Technorati Tags: .NET Security, File Permissions

in C++ gibt es ja das Resource Aquisition Is Initialization (RAII) pattern. Der Kern dieses Patterns besteht darin, dass ein Objekt bereits bei der Konstruktion die Ownership für eine Resource übernimmt und diese Resource bei seiner Zerstörung wieder frei gibt. Man wendet dieses pattern an, um Resourcen wie allokierten Speicher oder file handles sicher freizugeben. Dabei mancht man sich zu nutze, dass in C++ der Destruktor eines Objektes deterministisch aufgerufen wird, z. B. auch im Falle eine exception.

Dieses pattern ist sehr wichtig, um zuverlässige und robuste Software in C++ zu schreiben und ich nutze es regelmäßig. Nun hatte ich vor einiger Zeit in einem der Unittests in der Software, die ich für mein Unternehmen EmPowerTec schreibe, einen seltsamen Fehler in einem Unittest. Nach einer längeren Debugging-Session sah es so aus, als würden die Destruktoren für Objekte die in einer Methode auf dem Stack angelegt waren, beim Verlassen der Methode nicht mehr gerufen. Ein solches Verhalten führt mit Sicherheit zu Fehlern, wenn das RAII Pattern genutzt wird. Zunächst war ich darüber verblüfft, da ich mir nicht vorstellen konnte, dass ein derartig fundamentales Verhalten vom Microsoft C++ Compiler nicht richtig implementiert war. Tatsächlich war das aber der Fall, wie in folgendem Knowledge Base Eintrag beschrieben:

http://social.msdn.microsoft.com/forums/en-US/vclanguage/thread/8324a598-ad05-40e1-a271-6f64ce3b6008

Wie man dem Thread entnehmen kann, tritt das Problem auf, wenn man von einer C++/CLI Library eine native C++ library aufruft und diese mit inkompatiblen Einstellungen für das Exception handling übersetzt hat.

Und die Moral von der Geschicht,
Trau’ keinem Compiler nicht,

Unittests sollst Du machen,
Sonst hast Du nichts zu lachen

Viele Grüße,
Andreas

Technorati Tags: Microsoft Visual C++, RAII

kürzlich hatte ich folgende Situation:

In einer C#-Solution wurde eine in Managed C++ erstellte .NET Assembly referenziert. Sobald die C#-Anwendung eine Klasse aus der referenzierten Library benutzen wollte, gab es eine Exception der Form:


System.IO.FileNotFoundException: Die Datei oder Assembly "etocl, Version=1.0.3306.20332, Culture=de, PublicKeyToken=null" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
Dateiname: "etocl, Version=1.0.3306.20332, Culture=de, PublicKeyToken=null"


Die referenzierte Assembly fand sich aber wie es sein sollte im Arbeitsverzeichnis des C#-Programms. Um ein Protokoll des Ladevorgangs zu bekommen kann man nun folgenden Registry-Eintrag anlegen:


[HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) = 1


Danach enthält die Fehlermeldung eine Aufstellung der Pfade, die der Loader durchsucht hat:


LOG: Download von neuem URL file:///K:/Develop/et/etroot/src/apps/etoclide/bin/Debug/de/etocl.DLL.
LOG: Download von neuem URL file:///K:/Develop/et/etroot/src/apps/etoclide/bin/Debug/de/etocl/etocl.DLL.
LOG: Download von neuem URL file:///K:/Develop/et/etroot/src/apps/etoclide/bin/Debug/de/etocl.EXE.
LOG: Download von neuem URL file:///K:/Develop/et/etroot/src/apps/etoclide/bin/Debug/de/etocl/etocl.EXE.


und das Problem wird schnell sichtbar: der loader sucht im Unterverzeichnis “de”. Mit diesem Hinweis ausgerüstet sieht man schnell, dass das AssemblyInfo.cpp-file der referenzierten Library einen expliziten Eintrag für das locale enthielt:


[assembly:AssemblyCultureAttribute("de")]


Nach Entfernung dieses Eintrags und erneuter Erstellung der library  funktionierte dann auch alles wieder.

Fairerweise muss ich sagen, dass bereits die ursprüngliche Meldung einen Hinweis auf das Problem enthielt, allerdings nicht so deutlich:


System.IO.FileNotFoundException: Die Datei oder Assembly "etocl, Version=1.0.3306.20332, Culture=de, PublicKeyToken=null" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
Dateiname: "etocl, Version=1.0.3306.20332, Culture=de, PublicKeyToken=null"


Microsoft empfiehlt, den Registry-Eintrag wieder zu löschen da er zu einer Performance-Einbusse führen könnte.

Viele Grüße,
Andreas

Technorati Tags: .NET, Assembly loading

wer Microsoft Visio für die Erstellung von UML-Diagrammen nutzt kann sich mal diese Shapes auf softwarestencils.com anschauen. Sie sind angeblich besser als die mit Visio mitgelieferten Shapes.

Viele Grüße,
Andreas

Technorati Tags: Visio, UML

Liebe Leute, man muss nicht jede Mode mitmachen.
(Über die Qualität dieser site will ich hier ausdrücklich keine Aussage machen).

Viele Grüße,
Andreas