' schrieb:Hallo IchSelbst,
vielen Dank für deine Anleitung. Ich habe es gleich mal ausprobiert. Mal wieder ohne Erfolg. Woher weiß ich denn, welches VI als dynamisch eingebunden wird?
Die VIs aus excel.llb haben in meinem Programm als Speicherort z.B. C:Program FilesNational InstrumentsLabVIEW 8.2vi.libaddons_officeexcel.llbExcel Set Cell Font.vi. Woher weiß LabVIEW bei einer Apllikation jetzt wo sich dieses VI befindet, wenn ich es nicht in der "Mein Computer" Projektsturktur habe? Oder binde ich es deshlab als dynamisches VI mit ein?
Aber das mit den unterschiedlichen Excel-Versionen ist mir ein Rätsel. Vor ungefähr einem Jahr hat mein Vorgänger Applikationen/Setups von den beiden (nicht Mobility_Sequencer_Zugstatus) erstellt und diese Programme funktionieren einwandfrei bis heute. Jetzt habe ich die beiden Programme optimiert (Excel-Auslesevorgang wurde nicht verändert!) und meine Applikationen/Setups funktionieren nicht.
Durch diverse Updates im vergangenen Jahr veränderte sich Excel. Aber wieso macht das den Applikationen von vor einem Jahr nichts aus und nur meine funktionieren nicht?
Oder ist der Zugriff auf Excel vlt. nicht rückwärts kompatibel? Also wenn ich die Applikation mit der neusten Excel-Version 2003 mache, funktionieren die Applikationen mit einer niedrigeren Excel-Version nicht (nur so ein Gedanke).
Viele Grüße
Sven
Also ist schon eine ganze Weile her dass ich mich mit dem Report Generation Toolkit abgegeben habe. Aber die Office Applikationen haben die leidige Eigenschaft, dass sich deren ActiveX Interface mit jeder neuen Version mehr oder weniger verändert und die Art wie LabVIEW die Bindings mit einer ActiveX Library macht ist so dass ein Teil der Typkonversionen zur Compilierzeit vorgenommen wird, das heisst im Moment wo Du die Applikation baust. Wenn Du das Glück hast nur ActiveX Methoden zu verwenen die zwischen den Office Versionen keine Veränderungen untergangen sind, funktioniert die Applikation, ansonsten gibt halt das Laden des VIs wo die veränderte Methode angesprochen wird einen Fehler. Im LabVIEW Entwickelsystem wird dies als Broken Arrow in der VI Hierarchy sichtbar. In einer Built Applikation ist die Applikation nicht ausführbar.
Um das Letzte zu vermeiden haben die Entwickler des Report Generation Toolkits einen Trick verwendet. Manche der VIs die Du in Deiner Applikation einbaust sprechen die ActiveX Methoden nicht direkt an sondern rufen mittels dynamischer VI Server Aufrufe ein anderes VI in der von Dir vermeldeten _excelsup.llb auf.
Dieses Wrapper VI versucht das entsprechende _excelsub.llb VI zu laden und wenn das gelingt wird es ausgeführt. Ansonsten ist es halt Pech gewesen.
Das hat als Folge dass die Applikation noch immer ausführbar ist auch wenn die Excel Version auf dem aktuellen Computer inkompatibel damit ist wie einige der Excel ActiveX Methoden in der aktuellen Applikation compiliert sind. Sobald eine solche Methode aufgerufen wird, die nicht kompatibel ist mit dem aktuel installierten Office ActiveX Interface, wird das Laden des dynamischen VIs zwar einen Fehler verursachen (der von diesem VI im Error Cluster auch weitergegeben wird) und der Aufruf der Funktion geht in die Hosen, aber der Rest der Applikation kann normal weiterlaufen.
Ich glaube dass in 8.6 das Report Generation Toolkit etwas überarbeitet wurde aber das Prinzip sollte wohl noch dasselbe sein. In früheren Versionen hatte man auf der Installations CD verschiedene Versionen dieser _excelsup.llb und _wordsup.llb libraries für die verschiedenen Office Versionen. Solange man im LabVIEW Entwickelsystem ist kann man auch selber eine Version dieser LLB für das aktuell installierte Office machen indem man das VI _excelsup.llb/_Excel Dynamic VIs.vi lädt und während man die Ctrl-Shift-Taste gedrückt hält auf den Run Arrow klickt, was alle VIs im Speicher herkompiliert und allfällige Inkompatibilitäten auflösen sollte.
Einbinden der _excelsup.llb VIs in eine Applikation geschieht, indem man _excelsup.llb/_Excel Dynamic VIs.vi als dynamisches VI in in das Project einbindet. Selber habe ich dies damals vermieden indem ich einen Hack gemacht habe indem ich das New Report.vi angepasst habe. Dazu habe ich das darin verwendete Excel Find Application Directory.vi ersetzt mit einem VI das im Falle einer Built Applikation den Pfad zu einer im selben Directory als der Applikation liegenden _excelsup.llb zurückgegeben hat. Dann habe ich die richtige _excelsup.llb für die Office Version die auf dem Zielrechner nötig war auf dem Zielsystem in das Applikations Directory kopiert. Könnte natürlich auch noch so gemacht werden dass man alle Versionen der _excelsup.llb Libraries als Support Files mit verschiedenen Namen in den Applikation Installer mitnimmt und dann obengenanntes VI so anpasst um erst die Excel Version zu bestimmen und dann den Pfad zu der entsprechenen _excelsup.llb zurückzugeben.
Analoges gilt auch für die Einbindung des Word Interfaces.
Rolf Kalbermatter