Jochen Kalmbach’s Blog

Vielen Anfänger, welche C/C++ lernen wollen, suchen sich nach einer kostenlosen Entwicklungsumgebung und stossen dann früher oder später auf die Visual Studio 2008/2010 Express Edition.

Und ein Anfänger will natürlich gleich sichtbare Erfolge sehen und beginnt logischerweise gleich mit einer Fenster-Anwendung.

Leider enthält die VC2008/2010EE nur WinForms als graphische Oberfläche. Deshalb entwicklen die meisten dann nicht mit C/C++, sondern mit C++/CLI, was eine komplett andere Sprache ist und für die meisten nur zu Verwirrung führt.

Ich Rate jedem Anfänger davon ab VC 2008/2010 Express Edition für graphische Oberflächen zu verwenden, aus folgenden Gründen:

• Der WinForms-Designer ist miserabel, da er die Implementierung von Methoden in der h-Datei vornimmt, was spätestens zu Problemen führt, wenn man mehr als ein Form hat und auf Methoden/Properties des anderen Forms zugreifen will (da man dann zyklische Abhängigkeiten in den h-Dateien hat, die man nur lösen kann, wenn man die Implementierung in die cpp-Datei verlegt)
• Wenn man die Anwendung verteilen will, so muss man neben dem .NET-Framework auch die C-Runtime installieren; das muss man bei einer reinen .NET-Anwendung (z.B. C#) nicht
• C++/CLI ist primär als InterOp Sprache zwischen .NET und native Code gedacht; das sieht man auch schon daran, dass seit VC2008 auch der Data-Wizward für C++/CLI entfernt wurde. Daraus ergibt sich gleich der nächste Punkt:
• Der Data-Wizard wurde in VC 2008 entfernt um auch deutlich zu machen, dass der Focus auf native-managed InterOp liegt
• Ca. 99% aller Beispiele im Internet sind mit C#; man findet fast keine Beispiele in C++/CLI
• C++/CLI ist eine eigene Sprache und hat mit (ISO) C/C++ nichts zu tun; und das ganze zu mischen ist meistens noch viel sinnfreier, es sei denn, man weiss was man tut (was zu 99% nicht der Fall ist; zumindest in den Fragen, die ich aus den Foren entnehme)

Meine Empfehlung für Anfäger:
Wenn Ihr unbedingt graphische Oberflächen machen wollt, dann nehmt lieber C# (gibt es auch als Express Edition).

Meine Empfehlung für Microsoft:
Wenn Ihr auch mit VC++ Anfänger erreichen wollt, dann liefert bitte die MFC in der Express-Edition mit; oder bindet von mir aus wxWidgets ein

Wenn jemand mal interesse an den Tiefen der Shim-Datenbank hat, der kann gerne auf mein Projekt verweisen, welches ich in meinem englischen Blog gepostet habe:
The Shim Database

In Foren kommt oft die Frage: Mein C++/CLI Programm läuft nicht auf anderen Rechner! Was brauche ich damit es läuft?

Die Frage ist einfach zu beantworten, wenn wir davon ausgehen, dass das Programm mit VS2008 erstellt wurde:

1. Zuerst wird das .NET Framework benötigt (da C++/CLI ja die CLR verwendet). Aktuell ist dies die Version 3.5SP1:
   .NET 3.5 SP1 (Full download)
   Damit es aber auch Problemlos läuft wird min. noch dieser Hotfix anschliessend benötigt:
   An update for the .NET Framework 3.5 Service Pack 1 is available

2. Und da Du C++/CLI (also C++) verwendet hast, benötigst Du noch die C-Runtime DLLs, da C++/CLI (CLR) nur mit der DLL-Version der C-Runtime (CRT) verwendet werden kann:
   VC2008 Runtime with SP1 and ATL hotfix

PS: Falls man kein CLI (CLR / .NET) verwendet hat, so ist es meistens einfacher, wenn man statisch gegen die CRT linkt!

Wer von Euch kennt das Problem: Der Kunde hat ein Absturz oder einen Hänger Deines Programmes. Das einzige was Du bekommst ist ein Dump-File (z.B. entweder via WER oder durch eigenes schreiben von MiniDumpWriteDump).
Jetzt beginnt für Dich das Problem:

1. Welche Version hat der Kunde?
2. Welche Source-Files brauche ich für diese Version?
3. Wo zum teu.. sind nochmals die passenden PDBs und EXEn für diese Version?

Mit diesem Fragen braucht man sich nicht beschäftigen, wenn man bei seinem Build Prozess noch zusätzlich zwei Dinge einbaut

1. Source-Indexing
2. Symbols-Store

Source-Indexing (mit dem TFS)

Source-Indexing sorgt dafür, dass in die Debug-Symole (PDB-Dateien) auch zusätzlich noch ein verweis auf die richtige TFS-Version eingefügt wird. Dadurch kann der Debugger (z.B. VS) man mit der PDB-Datei genau den passenden Source aus dem TFS holen, mit dem die DLL/EXE gebuildet wurde.
Um dies zu machen braucht man zwei Dinge: “Debugging Tools For Windows” und “ActivePerl“). Das Source-Indexing findet sich bei den Debugging Tools im Unterverzeichnis “srcsrv” (also z.B. C:\Program Files\Debugging Tools for Windows\srcsrv). Da die “Skripts” (leider) in Perl geschrieben sind, ist auch noch ActivePerl notwendig. Es reicht aber, wenn man die ZIP-Datei runterlädt und vor dem Aufruf einfach den Pfad auch noch auf das entpackte ActivePerl setzt.

Damit beim Source-Indexing auch der korrekte TFS-Server verwendet wird, muss man in der Datei “srcsrv.ini” die Zeile mit “MYSERVER” auf den richtigen TSF zeigen lassen.
MYSERVER=http://my-tfs-machine:8080

Jetzt muss man nach einen Build nur noch das Source-Indexing aufrufen und angeben, wo denn der Workstore und die PDBs liegen. Ich gebe der Einfachheithalber immer den Root aller Projekte an, welche ich gebuildet habe. Die Natchdatei sieht dann z.B. so aus (es kann auch direkt als eigenes Task in msbuild laufen):

rem Merke mit mal den aktuellen Pfad, was die Root meiner Projekte und Ausgabe ist
set srvOrgDir=%CD%

rem Setze wieder den ursprünglichen Pfad
cd /D %srvOrgDir%


Alternativ kann man natürlich auch das srcsrv-Verzeichnis im TFS ablegen (so hab ich es gemacht), dann muss man nicht sicherstellen, dass man auf dem Build-Rechner auch die Debugging-Tools installiert hat.

Jetzt sollten nach einem Build alle PDB-Dateien mit der korrekten TFS-Version indiziert worden sein (dies erkennt man daran, dass ziemlich weit hinten in der PDB-Datei Einträge mit “MYSERVER” kommen…; kann man z.B. in Notepad anschauen).

Symbol-Store

Oben haben wir jetzt die PDB-Dateien mit dem passenden Verweis auf den TFS ausgestattet. Jetzt müssen wir nur noch sicherstellen, dass wir zu einem beliebigen späteren Zeitpunkt nicht mehr nach dieser PDB-Datei (und den dazugehörigen EXEn) suchen müssen. Dies geschieht am einfachsten mit dem “symstore” aus den Debugging Tools for Windows. Dies speichert einfach alle PDBs/EXEn in ein Verzeichnis (am besten ein Netzwerkverzeichnis, wenn es später mehrere Verwenden wollen).
Das ablegen erfolgt dann ganz Simple durch:

.\Tools\SymStore\Symstore.exe add /r /f .\*.* /s G:\MyProject\SymbolStore\Files /t "Project Name"


Das war alles

Einstellungen in VS

Ok, fast… denn man will das ganze ja auch noch verwenden… dazu muss man in VS noch ein paar Einstellungen machen, da per default der “Source-Server” deaktiviert ist. Dies muss aktiviert werden:

Jetzt muss man noch den Pfad zu den zuvor abgelegten Dateien eintragen:

Bekommt man jetzt ein Dump oder will in dieser EXE/DLL debuggen, so werden die Sourcen direkt vom TFS geholt (und in einem temporären Verzeichnis gespeichert) und man kann dies dann direkt debuggen.

Ich hoffe, dass hilft dem ein oder anderen.

PS: Beide Verfahren werden übrigens auch intern von Microsoft schon sehr lange eingesetzt (deswegen auch das Source-Indexing in Perl; PowerShell gab es damals noch nicht). Die gesamten Windows Sourcen sind so indiziert und (der wer darf ) können dann via CCP die passenden indizierten PDB-Dateien abgefragt werden, welche dann z.B: in VS/WinDbg die passenden Source runterlädt.

PPS: Wer das ganze noch für SubVersion haben will, kann es bei Stefan nachlesen:
Source Server und Symbol Server Setup mit Subversion

Wer zufällig vom 9.11. bis 13.11. auf der TechEd Europe in Berlin ist, darf gerne mal im Technical Learning Center (TLC) an den Ask-the-Expert (ATE) booths vorbeischauen, wo ihr mich treffen könnt

Wir haben hier für die ListBox ein eigenes Template gemacht, dass eben alle ListBoxen bei uns in der Anwendung gleich aussehen… dabei haben wir einfach das Beispiel aus der MSDN verwendet: ListBoxItem ControlTemplate Example

Eigentlich sollte man ja meinen, dass dies Beispiel zumindest einigermaßen funktioniert… leider weit gefehlt…

Das Problem ist: Sobald wir ein eigenes DataTemplate für spezielle Daten gemacht haben, hat ein Klick auf ein Element nur dann reagiert, wenn entweder genau auf den Rahmen des Items geklickt wurde oder genau auf den Text:

Es ist also relativ schwer z.B. das “!” genau zu treffen…wir haben ewig gesucht, bis wir endlich den Grund gefunden haben… (dank Franks Unterstützung haben wir es mittels Snoop und der Event-Ansicht gefunden): Der Border in dem ControlTemplate hat keine Hintergundfarbe. Somit ist der Border “durchsichtig” (bzw. “x:Null”), was dazu führt, dass ein Klick auf den Border nicht vom Border verarbeitet wird, sondern vom darunterliegenden Scroll-Container… und der macht natürlich hier nichts damit…
Hier ist auch ein Beispielprojekt (VS2008), damit man es mal selber probieren kann.

Für uns jetzt mal die Lösung: Wir setzen einfach die Hintergrundfarbe des Borders des ControlTemplates auf “Transparent”, dann wirken sich jetzt überall die Klicks auf die ListBox aus… danke an Hendrik für diesen Hinweis!

Seit einigen Tagen konnte ja schon MSDN Abonenten die Beta von Visual Studio 2010 runterladen. Ab sofort ist es auch als öffentlichen Download verfügbar:
Microsoft Visual Studio 2010 Ultimate Beta 2 - ISO

Und wer sich gleich noch über die Neuerungen in der MFC informieren will (ja die gibt es!), kann sich hier ein Video anschauen:
Pat Brenner: Visual Studio 2010 - MFC and Windows 7

Wer unbedingt gegen die DLL-Version der CRT/MFC linken will/muss, der steht seit dem ATL-Security-Update vor dem Problem, dass neu übersetze Projekte jetzt zwangsläufig die neue CRT-Version im Manifest eingetragen hat. Dieses verhalten wurde von MS einfach so eingeführt, ohne dies zu kommunizieren. Dies hat natürlich zu etwas Kritik geführt. Aber “Security” rechtfertigt ja alles.
Bisher wurde nach einem Update von VS2008 (also z.B. durch das Feature-Pack oder durch den SP1) im Manifest immer noch die Versionsnummer der RTM-Version eingetragen. Deshalb war es auch jetzt sehr verwirrend, dass plötzlich eine neue Version eingetragen wird, ohne dass man irgend etwas am Projekt geändert hat. Bisher war es nötig, dass man als Define ein “_BIND_TO_CURRENT_CRT_VERSION=1″ setzt. Erst dann wurde die aktuelle auf dem Enticklungsrechner verwendete Version eingetragen.

Aber nun ist es nunmal anders und wir sind entweder gezwungen das Security-Update von VS2008 nicht einzuspielen (was ich aktuell als einzige Lösung hier im Automatisierungs-Bereich habe, wenn man auch alte Systeme updaten muss) oder auf neuen Systemen das passende vcredist zu installieren.

Nur jetzt ist wieder die Frage: Welches ist denn nun die “richtige” vcredist…
Hier die Auflistung der aktuell verfpgbaren Versionen:

• VC2008 Runtime with SP1 and ATL hotfix
• VC2008 Runtime with SP1
• VC2008 Runtime with Feature Pack
• VC2008 Runtime with ATL hotfix
• VC2008 Runtime (RTM)

Wer ganz sicher gehen will, der sollte ab sofort nur noch das oberste installieren!

In letzter Zeit mach ich mehr mit WPF rum. Hierbei spielt ja das MVVM-Pattern eine große Rolle. Darin werden für änderbare Listen oft eine “ObservableCollection” verwendet. Diese informiert alle beteiligten darüber, wenn ein Element gelöscht oder hinzugefügt wurde. Auch unterstützt es dabei das Feature eines “CurrentItems”. Nur konnte ich dieses bisher nie über irgendwelche Methoden aus dem View-Model heraus ansprechen… immer nur durch WPF-Elemente war dies möglich. So hat z.B. eine ListBox das Property “IsSyncronizedWithCurrentItem“. Damit werden Änderungen am “CurrentItem” durch andere Controls (z.B. durch andere ListBoxen) automatisch auch in alle “angeschlossenen” übernommen.
Nur aus meinem ViewModel war es mir noch nicht gelungen das “CurrentItem” zu setzen (z.B. nach Button-Klick), da ich keine Methode oder Property finden könnte.
Jetzt hab ich es endlich gefunden wie man auf das “CurrentItem” zugreift: Man muss sich zuerst die “DefaultView” der Collection holen. Dann kann man auch die Position des aktuelle Items ändern.
z.B. um das “CurrentItem” zu setzen:

var dv = CollectionViewSource.GetDefaultView(viewModel.MeineCollection);
dv.MoveCurrentTo(viewModel.MeineCollection[1]);

oder um das CurrentItem auszulesen:

var dv = CollectionViewSource.GetDefaultView(this.List);
MessageBox.Show(dv.CurrentItem.ToString());

Hier gibt es auch ein kleines Beispielprojekt: WPF_CurrentItem.zip

Nachdem ich auf meinen Wohnzimmer-Rechner schon vor einigen Wochen von Mac OSX auf Windows 7 Ultimate umgestiegen bin, hab ich das ganze vor zwei Tagen auf mit meinem Hauptrechner gemacht. Hier hatte ich vorher Vista 64 Ultimate drauf. Da ich mit der Partitionierung nicht ganz zufrieden war, hab ich mich entschieden alles neu zu installieren und das Ding ganz Platt zu machen.
Zuerst habe ich mit Acronis TrueImage Home 2010 eine Sicherung gemacht und dann die Windows 7 Ultimate x64 installation gestartet. Ich muss sagen: Die Installation hat ca. 25 min. gedauert und er hat alle Hardware in meinem Rechner erkannt (RAID, Soundekarte (die kannte Vista nicht), usw.).

Alles im allem muss ich sagen, dass ich sehr zufrieden bin. Leider musste ich dann natürlich wieder alles installieren, was man so braucht… und die Daten wieder rüberkopieren.

Also, ich kann es nur empfehlen auf Windows 7 umzusteigen. Es macht einen schönen und performanten Eindruck.

Jetzt dürft ihr auch gerne zu meiner Windows 7 HouseParty kommen

Es soll ja tatsächlich Leute geben, die den Unterschied der beiden Funktionsweisen noch nicht kennen. Liest man die MSDN-Dokumentation, so kann man erkennen, dass GetWindowText nur zuverlässig für den eigenen Prozess funktioniert. Die Begründung findet man dann bei “The Old New Thing“.

Und damit es jeder auch selber nachvollziehen kann, dass GetWindowText wirklicht nicht zuverlässig für andere Prozesse geht, hab ich hier ein kleines Beispielprogramm:
http://blog.kalmbachnet.de/files/GetWindowText.zip

Wie man aus dem verwiesenen Blog-Eintrag erkennen kann, verwendet intern “GetWindowText” nur WM_GETTEXT, wenn es ein Fenster im eigenen Prozess ist. Sonst wird ein “secret-buffer” verwendet. Ein WM_GETTEXT wird nicht gesendet!

Die ZIP-Datei besteht aus zwei Projekten (Release-EXEn liegen auch drin, damit man es nicht mal mehr selber übersetzen muss).
1. TargetApp: Dieses Wizard erzeugte Fenster-Programm verarbeitet selber die WM_GETTEXT Message und gibt als String “Booga!” zurück. Durch Aufruf von “Help|About…” kann man nachweisen, dass “GetWindowText” hier den String “Booga!” zurück gibt. Es verwendet also WM_GETTEXT um den Text zu erhalten.

2. SpyApp: Dieses Wizard erzeugte Fenster-Programm mach nach Aufruf von “Help|About…”: Es ermittelt das Fenster-Handle des TargetApp durch den Klassennamen (TARGETAPP). Dann kommt der eigentlich Aufruf zu “GetWindowText”. Der zurückgegebene Text wird dann in einer MessageBox angezeigt.

Und dreimal dürft Ihr Raten, was das für ein Text ist (nein, es ist nicht “Booga!”).

PS: Auch durch den Aufruf von diversen anderen Funktionen wie AttachThreadInput und GetFocus ändert sich an dem verhalten nichts, dass GetWindowText nicht WM_GETTEXT verwendet.

PPS: Wer sich für den Auslöser dieses Posting interessiert, der kann es hier nachlesen:
aktives Control ermitteln
Dort behauptet der Poster, dass “GetWindowText” intern WM_GETTEXT sendet. Und das stimmt natürlich nur für den eigenen Prozess, nicht aber für externe (in diesem Thread geht es nur um externe Prozesse).

[ADD: 2009-10-11]
PPPS: Wer sich wundert, warum im Source-Code der SpyApp sowas komisches wie “AttachThreadInput” aufgerufen wird, der sollte einfach nur den obigen Thread lesen… dieser Aufruf ist einfach sinnlos und kann getrost entfernt werden; ein anderer behauptet in dem Thread, dass es “unbedingt notwendig” ist, damit das “GetWindowText” intern ein WM_GETTEXT verwendet (was es ja für externe Prozesse nicht tut, wie das Beispiel ja schön zeigt).

Nun ja, zumindest in der embedded Welt:
Silverlight & Windows Embedded CE 6.0 R3: ein Traumpaar!

Grob zusammen gefasst: Es wird Silverlight auf Windows Embedded geben, aber das “Code-Behind” ist C/C++ über COM!

Wenn dass mal nicht ein Schritt in die richtige Richtung ist!

TFS ist ja was wunderbare… nur wer bisher ohne sowas gearbeitet hat, oder cvs genutzt hat, der hat meistens seine Änderungen direkt im Header/Footer seiner cpp/h-Datei reingeschrieben. Dies hatte den großen Vorteil, dass man direkt zwei Dateien vergleichen konnte und sofort gesehen hat, wer was gemacht hat.
Dies geht so mit dem TFS nicht. Man benötigt immer den Team Explorer (oder VS) um die Kommentare einer Änderung zu sehen.
Es ist also so nicht so einfach möglich “disconnected” zu arbieten und trotzdem zu jeder Datei die ganzen Änderungen (zumindest anhand den Kommentaren) zu erkennen.

Im cvs gab es sowas wie ein “keyword-substitution“. Damit konnte man z.B. “$log$” in einen Kommentar seines Source-Codes einfügen und das cvs hat beim Check-In automatisch den Kommentar in die Source-Datei eingefügt.

Sowas habe ich auch für den TFS gesucht aber nicht gefunden. Mir wurde an diversen stellen gesagt, das sowas nicht geht…

Jetzt habe ich mich gestern selber drangemacht es zu probieren

Und voila: Es klappt…
Habe nun ein kleines VS-PlugIn geschrieben (Check-In Policy), welche beim Check-In in den TFS den Kommentar in die Source-Datei reinschreibt, wenn dort ein “$log$” Eintrag vorhanden ist.

Ich bin jetzt wirklich begeistert!
Das Ding tut einwandfrei… hab es jetzt sogwar soweit, dass man es ganz hübsch parametrieren kann; d.h. man kann ganz frei “Templates” vorgeben, wie die Kommentare aussehen sollen.

Hier mal zwei Beispiele:

Man kann die Kommentare entweder von oben nach unten einfügen lassen:

/**************************************************************
 *
 *  Description: ...
 *
 *  History
 *  -------
 *
 *    Date   |Author | Comment
 *  ---------+-------+----------------------------------
 *  24.07.09 | kalmb | sdfsdf sdfsdf sdfs
 *  24.07.09 | kalmb | Zeile 1
 *           |       | Zeile 2
 *           |       | Zeile 3
 *           |       | Zeile 4
 *  24.07.09 | kalmb | sdafsdgdgdfsgsdfgdfsgdsfgdfs
 *  24.07.09 | kalmb | fgd dsfgdfsgdsfgdfgd
 *  24.07.09 | kalmb | asdasdf sadfsfsfsdfasdfas
 *  $log$
 *
 **************************************************************
 */

Oder auch von unten nach oben (wie cvs):

/*
 * $log$
 * 
 * Comment: Nochmals eine Änderung
 * User: DOMAIN\name
 * DateTime: 2009-07-23 22:04:22
 * Change: edit
 * 
 * Comment: dsfsdfsdfsd
 *          sdfsdfgsdfhgf hdfhfdghdfghfgdh
 * User: DOMAIN\name
 * DateTime: 2009-07-23 22:00:36
 * Change: edit
 */

Aus meiner Sicht ist dies das beste PlugIn, was ich seit langem gesehen habe

Was meint Ihr dazu?
Wer interesse hat, darf sich gerne bei mir melden…

EDIT: Gestern hab ich meine “Keyword Substitution Check-In Policy” auf Codeplex veröffentlicht: http://logsubstpol.codeplex.com/

Wer schon mal extensiver mit XAML (WPF) zu tun gehabt hat, der weiss: Debugging von DataBinding ist nicht so ganz trivial…

Ich hatte heute einen ganz simplen Cut-n-Past Error: Habe ein Binding Expression der Form

<Label Text="{Binding Path=Test}" />

in ein MultiBinding eingefügt… wer nun schon mal mit MultiBindings gearbeitet hat weiss, dass man dazu nicht die “Kurzform” mit den geschweiften Klammern verwendet, sonder das ganze in die “Elemente” reinschreibt… also aus dem obigen Beispiel wird dann ein

<Label>
  <Label.Text>
    <Binding Path="Test}" />
  </Label.Text>
</label>

So… das sieht ja einfach aus jetzt hab ich aber beim Copy-and-Paste dummerweise die geschweifte Klammer am Ende mitkopiert… dann noch einige Zeit weitergearbeitet… und dann wollte ich starten… lies sich auch alles wunderbar compilieren…
Nach dem Start kam aber das böse Erwachen…. ich hab min. 1 Stunde gesucht (und dabei in den tiefen des .NET-Source-Codes debuggt) bis ich den Fehler gefunden habe.

Der Grund: Es kam nicht wie sonst üblich eine Debug-Ausgabe, dass er das Property “Test}” nicht finden kann!
Sondern es kam eine “System.FormatException”… so und jetzt Ihr (nein, das war schon die InnerException!)

Also, nach langem suchen hab ich tatsächlich ein Bug in WPF gefunden
Wenn Trace-Ausgaben aktiv sind, dann wird der Text in “Path” einfach ungeprüft der StringBuilder.AppendFormat-Methode als Formatstring übergeben… da aber in meinem Fall eine geschweifte Klammer drin war, konnte der String natürlich nicht erfolgreicht formatiert werden… deshalb die Exception (die mir aber nun mal gar nicht weitergeholfen hat).

Hab es mal gemeldet:
VS2008-SP1: FormatException in MS.Internal.AvTrace if Binding.Path contains curly braces…
VS2010-B1: FormatException in MS.Internal.AvTrace if Binding.Path contains curly braces…

Bitte abstimmen, ob Ihr den auch wichtig findet… (ich persönlich finde ja das ganze Debuggen des DataBindungs hundsmiserabel).

Ich bin tatsächlich von meinem Standard-Suchanbieter “google” zu “bing.com” gewechselt
Bisher überzeugt mich Bing! Auch die “Related Searches” sind recht gut. Mir ist gerade noch nichts (wesentliches) aufgefallen, wo google besser sein sollte… (ausser bei Newsgroups-Suche).
Ich werde dies jetzt mal so lassen und mal schauen, wie es sich entwickelt.
Er findet sogar bei der Suche nach “CreateFile” sofort die passende API! Das konnt live-search nicht (da kam es erst auf der 2. Seite).
Auch gefällt mit der Hintergrund auf der Bing-Startseite besser als bei Google; auch die kleinen Infos zu dem Bild sind sehr hübsch…

Zumindest habe ich aktuell auch mehr vertrauen zu MS als zu Google, was die Speicherung “privater Daten” angeht. Google wird mir da langsam zur “Krake”…

PS: Was man machen sollte, ist die Ländereinstellung auf “United States (Deutsch)” umzustellen (ganz oben rechts); dann hat man auch alle neuen Features

Um von einer native C/C++ Applikations auf das Virtual Earth SOAP-API zugreifen zu können sind einige Schritte notwendig.
In einem Beispielprojekt hab ich diese mal realisiert und auf MSDN Code Gallery zur Verfügung gestellt.

Das Projekt kann hier runtergeladen / angeschaut werden:
Virtual Earth SOAP API with C/C++ via gSOAP

Hier ist ein kleines Rätsel aus meiner C++/CLI Schulung, die ich letzte Woche gehalten habe:

Der Code wurde mit “/clr” kompiliert (das ist wichtig).
Kann mir jemand sagen, wie der genaue Callstack innerhalb der Methode “Foo” aussieht?
Und: Wie kann man indirekt nachweisen, was genau passiert?
Meine Schulungsteilnehmer dürfen natürlich nicht mitmachen, die wissen es ja schon

struct V
{
  V() {}
  V(const V &v) 
  {
    this->i = v.i;
  }
  int i;
};
 
class C
{
public:
  void CallFoo()
  {
    V v;
    Foo(v);
  }
  virtual void Foo(V v)
  {
    // TODO: Wie sieht der Callstack aus?
  }
};
 
int main()
{
  C c;
  c.CallFoo();
}

Lösungen können als Kommentare gepostet werden.
Ein kleiner Hinweis noch: VS208 zeigt nicht den exakten Callstack an, aber er zeigt, dass da irgendwas noch passiert sein muss

Ist Euere Firma gerade dabei, doch einmal die .NET-Welt zu erkunden?
Habt Ihr aber sehr viel C/C++-Code, der am besten Wiederverwendet werden soll?

Dann wäre vielleicht ein Einstige in C++/CLI eine gute Lösung und bestehende Buisness-Layers .NET-Konform zu machen oder den Datenaustausch mit .NET-Dingen zu ermöglichen.

Letzte Woche habe ich eine Schulung über C++/CLI durchgeführt.
Das Thema ist sehr umfangreich und beinhaltet u.a. eine Einführung in .NET, native InterOp, COM-InterOp / MFC-InterOp, usw.

Wer also Interesse an einer Schulung hat, darf sich gerne bei mir oder SoftwareAcademy melden.

Als ich vor drei Jahren zum ersten Mal x64 Systeme getestet habe, musste ich sehr schnell feststellen, dass es (leider) keinen Jet-Treiber gibt.
Nun scheint sich bei MS doch ein Wandel vollzogen zu haben. Office 2010 wird es zumindest als (native) x64-Version geben. Somit ist die Hoffnung groß, dass es vielleicht auch einen “offiziellen” Jet-Treiber für x64-Applikationen geben wird.

Wir lassen uns also überraschen…

Da Windows ja immer noch reiner native Code ist stellt MS jetzt ein Windows-7 .NET-InterOp-Sample zur Verfügung.

Viel Spass damit…