Problem bei Excel-COM-Schnittstelle

Ahalex

Hallo!

Gibt es eine Möglichkeit, beim Kompilieren einer Codezeile das Betriebssystem zu beachten? Eine Art Makro oder sonstiges?

In der Art:

#ifdef WINVISTA
    code code code
#ifdef WINXP
    code code
#endif

Wichtig ist eben, dass der Compiler bereits weiß, bei welchem Betriebssystem er welche Zeile "nehmen" muss.

Vielen Dank.

Grüße,
Ahalex

loki1985

die compiler bringen eigene defines mit, die aber abhaengig vom compiler sind. also bei MinGW sehen die halt anders aus als bei MSVC.
duerfte aber auch paar gemeinsame geben. irgendwas mit WINVER, plus paar underscores davor.

einfach mal doku lesen.

allerdings muss bewusst sein dass das nur bedingt was bringt, da compiler-umgebung ja nicht zwangslaeufig mit der runtime-umgebung uebereinstimmen muss.

Ahalex

Danke!

Kennt hier zufällig jemand ebensolche defines für das Visual Studio 2008?

Martin Richter

Die Nutzung der SDK Headerhaben sich in den letzten Jahren kaum geändert:

Using the Windows Headers
http://msdn.microsoft.com/en-us/library/aa383745(VS.85).aspx

drecksack

Hier gibts eine Übersicht:
http://predef.sourceforge.net/

Mmacher

Ahalex schrieb:

Gibt es eine Möglichkeit, beim Kompilieren einer Codezeile das Betriebssystem zu beachten? Eine Art Makro oder sonstiges?

Ähem, dies bedeutet ja, daß Du zwangsläufig zwei verschiedene Applikationen erzeugen mußt (eines mit WINVISTA Code und eines mit WINXP Code)?
Nicht gerade kundenfreundlich, würde ich sagen.

Ich meine nur, Du kannst ja beide Code-Zweige in Deiner einzigen Applikation drinlassen und zur Laufzeit per if-Abfrage entscheiden welche der beiden Codes ausgeführt werden.

Stichwort: GetVersionEx()

Just my 5 cents,
Martin

Ahalex

Hallo!

Erstmal danke für alle Antworten!
Ich bin mir nun da ich in den genannten Beiträgen etwas recherchiert habe nicht sicher, ob ich mein Problem genau genug geschildert habe und/oder ob es hier richtig verstanden wurde oder aber ich die Lösungsansätze richtig verstanden habe, darum möchte ich das nochmal anders erklären.

Das Problem richtet sich hier nicht in Richtung der Zielplattform, sondern auf die Entwicklerplattform.

Eine Software wird auf mehreren Betriebssystemen (WIN XP, WIN7) entwickelt. Wenn Entwickler A auf WIN XP den Code kompilieren möchte, benötigt er Codezeile

code a, b, c

Wenn Entwickler bei mit seinem WIN7 das gleiche Projekt kompilieren möchte, muss er aber, um kompilieren zu können die gleiche Zeile ändern in

code a, b //c

Das bringt diese Zeile mit sich, dass sie auf unterschiedlichen Betriebssystemen unterschiedlich geschrieben sein muss.

Da hier jedes Mal eine Änderung vorgenommen werden muss, welche keine Auswirkungen auf die Software hat, sondern lediglich dem erfolgreichen Kompilieren dient, war meine Frage diesbezüglich, ob es eine Möglichkeit gibt, das Problem zu lösen, ein Makro ähnlich dem #ifdef _DEBUG o.Ä.

Hoffe ich habe das besser verständlich erklärt.

Falls eine der genannten Links die Problemlösung bereits erklärt, bitte ich um Entschuldigung und hoffe, nochmals mit dem Zaunspfahl zugewunken zu bekommen.

Martin Richter

Das ist doch Quark.

Mein Entwicklungssystem entscheidet doch nicht darüber wie etwas zu kompilieren ist.
Ich kann ein XP System haben und dennoch für Windows 7 entwickeln...
Was hat das Entwicklungssystem mit dem Code zu tun, den Du kompilierst?

Ahalex

Wäre es Quark, hätte ich es gegessen und nicht geschrieben. Und sich so einen langen Text auszudenken wäre mir auch zu zeitintensiv gewesen.

Beim Excel-Export ist der Import einer DLL notwendig: mso97.dll
Hier werden nun in der Zeile des includes verschiedene rename´s vorgenommen. Eines davon ist nun mal vom o.g. Problem betroffen.

Martin Richter

Ahalex schrieb:

Wäre es Quark, hätte ich es gegessen und nicht geschrieben. Und sich so einen langen Text auszudenken wäre mir auch zu zeitintensiv gewesen.

Beim Excel-Export ist der Import einer DLL notwendig: mso97.dll
Hier werden nun in der Zeile des includes verschiedene rename´s vorgenommen. Eines davon ist nun mal vom o.g. Problem betroffen.

Und gerade so etwas ist Blödfug.

Ich habe schon vor Jahren dazu Tipps gegeben:
http://blog.m-ri.de/index.php/2008/08/03/tipps-tricks-import-durch-include-ersetzen/

Führe auf einem Rechner den #import durch und Compiliere. Du erhältst tlh und tli Dateien.
Nun füge diese direkt in Deinem Projekt ein ohne kommentiere den #import aus.
Schon kann an jedem Rechner das Projekt compiliert werden und diese mso97 Datei muss nicht mal drauf sein.

Der #import ist nichts anderes als eine Abkürzung von erzeugen der tlh/tli Dateien und anschließendem include dieser Dateien.

Das Ganze beschleunigt sogar Deinen Compile.

PS: Schildere demnächst direkt Dein Problem. Und nicht was Du Dir als Hilfe für Deine Lösung ausdenkst.

Ahalex

Okay, da kommen wir der Sache sehr nahe. Lösungsansatz ist nachvollziehbar, funktioniert aber für diesen speziellen Fall nicht.

Durch die genannte Methode wird lediglich das Verfahren abgekürzt, sodass es nicht jedes Mal notwendig ist, die .tli und .tlh-Dateien zu erzeugen, wenn ich das richtig verstanden habe. Jedoch ist weiterhin das Projekt dann nur auf den Rechnern nutzbar, bei denen es vorher auch ging. Die Namenskollision, die durch das rename "CommandBars" auf verschiedenen Rechnern entsteht, wird so quasi durch die im Blog beschriebene Methode nur "fest eingebaut" und ist dann durch Auskommentieren der entsprechenden Stelle nicht mehr änderbar.

Das Problem-rename:

rename ("CommandBars", "_CommandBars")

Es scheint also speziell mit dem Namen CommandBars verbunden zu sein.

Edit: Scheint nicht vom Betriebssystem abzuhängen. 3. Rechner mit XP zeigt gleiches Verhalten wie WIN7 Rechner.

Mmacher

Ich verstehe da nur Bahnhof....

Ich kann Dir nur empfehlen, das Problem und die aktuelle Situation zu beschreiben. Nicht das drumherum um den Brei zu erklären.

Also nochmal ganz von vorne, erstmal die aktuelle Situation erfassen:

Ahalex schrieb:

Eine Software wird auf mehreren Betriebssystemen (WIN XP, WIN7) entwickelt.

Wieviele Entwicklungssysteme habt Ihr denn?
Haben alle die gleiche Version? Z.B. auf allen Rechnern sind Visual Studio 2008 installiert?

Des weiteren gehe ich davon aus, daß auf allen Entwicklungssystemen die gleiche aktuelle Windows-SDK installiert sind.

Zuerst klären wir diese Fragen, dann kommt der nächste Schritt, ok?

Martin

Ahalex

Danke für deine Hilfe! Allerdings wurde das Problem gerade gelöst.

Werde morgen beschreiben wie und was und warum, falls jemand das Problem ebenfalls haben sollte, habe bloß gerade keine Zeit mehr.
Habe auch mal den Threadtitel umbenannt...war etwas vom eigentlichen Thema weg.