Erste Gehversuche mit der englischen Version von Visual Studio 2008 haben mich begeistert: Click Once Deployment von Office-Erweiterungen funktioniert perfekt.
Seit gestern bin Besitzer der deutschen Version und bin beunruhigt. Beim Veröffentlichen eines Projekts kommt der Warnhinweis:
Der Wert des PublicKey-Attributs in Visual Studio-Tools für Office System 3.0 Runtime entspricht nicht dem der Datei "c:\Programme\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\VSTOR30\de\vstor_lp_de_30.exe".
Das hat zur Folge, dass beim Installieren auf dem Zielrechner mittels setup.exe ein Fehler auftritt, der berichtet, dass die genannte Datei nicht das Original ist, die Installation bricht ab. Es hilft nur, VSTOR in der deutschen Fassung vorher zu installieren.
Irgendwas mache ich wieder falsch, nur was?
Nachtrag vom Mai: Peter Monadjemi hat es herausgefunden und in unser Buch mit aufgenommen. Man muss das PublicKey-Attribute der deutschen package.xml gegen das der englischen tauschen. Eigentlich ganz einfach.
Nachtrag vom August: Wegen der beiden Anfragen hier noch ein paar Details. Im Ordner C:\Programme\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\VSTOR30 befindet sich die Datei procuct.xml und hält unter PackageFile den ProductKey. Im Unterordner DE befindet sich eine Datei package.xml. Deren Eintrag ProductKey muss mit dem ersten übereinstimmen (unser Buch Seite 552).
Es hat mich geärgert, dass es wohl schon unter Outlook 2003 nicht mehr möglich war, per Schaltfläche zwischen der Ordneransicht und der dem Ordner zugeordneten Webseite hin- und herzuschalten.
Auch Outlook 2007 brachte dieses Feature nicht zurück. Also: Selbst ist der Anwender! Der folgende VBA-Code erledigt die Angelegenheit:
Sub ToggleWebView()
On Error Goto errH
Dim ex As Explorer
Dim fld As Folder
Set ex = ActiveExplorer
Set fld = ex.CurrentFolder
'ex.CurrentFolder.WebViewURL = " http://www.dr-e-pfeifer.net"
fld.WebViewOn = Not fld.WebViewOn
Set ex.CurrentFolder = fld.Parent
Set ex.CurrentFolder = fld
Exit Sub
errH:
End Sub
Tricky ist nur der Wechsel von CurrentFolder, damit der Effekt sofort sichtbar ist.
Nachdem sich die Wogen um den Rechenfehler in Excel 2007, der wohl in der Tat ein Darstellungsfehler war (was ihn nicht besser macht), gelegt haben, ist mir etwas doch sehr Seltsames untergekommen. Mircosoft hat die Implementierung des Analyse-Add-Ins selbst in die Hand genommen. Auf diese Weise ist manch Fehler verschwunden, auch in der Online-Hilfe.
Doch Folgendes ist zu beobachten: Die ehemals deutschsprachigen (lokalen) Namen für die Funktionen kommen mit den nunmehr englischen nicht zurecht. In "alten" Arbeitsmappen ist dann statt des Ergebnisses die Fehlermeldung #NAME? zu lesen. Nur ein Klick in die Bearbeitungsleiste mit anschließendem ENTER (oder eine angepasste VBA-Lösung zur Automatisierung) löst den Konflikt. Ein Blick in die XML-Dateien des ZIP-Ordners zeigt einige Hintergründe.
Das ist aber leider nicht alles: Schreibt man in eine Zelle
=ZW2(100;10%)
(eine einfache Aufzinsungsformel, die in der Hilfe noch etwas aufgepeppt wird), so entsteht der unerwartete Fehler #BEZUG! (auch im Beispiel der Hilfe). Und das, obwohl kein Bezug benutzt wurde. Und auch wenn ein solcher genommen wird, bleibts beim gleichen Fehler.
Noch verwirrender wird das Ganze, wenn man eine "alte" Mappe mit dieser Formel unter 2007 öffnet. Aus der Formel wird dann
='ZW2'(100;10%)
und es erscheint der Fehler #NAME?.
Entfernt man vorsichtig die beiden Apostrophe, so wird das Ergebnis korrekt angezeigt!?
Und nun das Unerfreulichste: Versucht man eine Mappe, in der die Apostrophe noch drin stehen, ins neue Format zu konvertieren, so meldet Excel korrupte Dateiteile und ersetzt die schlechte Funktion durch noch schlechteren Text: #NAME?
(Stand 23.1.08, SP 1)
Nachtrag vom August 2008 in Zusammenhang mit der Erstellung des Maxibuchs: Der Hinweis von Thomas Ramel ist prinzipiell richtig, funktioniert aber im konkreten Fall nicht. Die Apostrophe können zwar durch Suchen/Ersetzen entfernt werden, der Trick von Thomas erzeugt dann allerdings den Bzugsfehler.
Im Blog The Microsoft Office Word Team's Blog gibt es eine schöne (weil einfache) Einführung in das Erstellen eigener Quellangaben-Formate in Word-Dokumenten.
Nun werden viele Anwender ggf. damit beginnen, die integrierten XSLT-Stylesheets anpassen zu wollen. Damit diese Anpassungen sich in der Liste der Styles deutlich von den vorhandenen unterscheiden, sind mehrere Schritte notwendig:
- Im Tag <xsl:template match="/"> ist der Eintrag der Form
<xsl:when test="b:Version">
<xsl:text>nnnn.n.nn</xsl:text>
</xsl:when>
<xsl:when test="b:OfficeStyleKey">">
<xsl:text>name</xsl:text>
</xsl:when>
zu entfernen.
- Statt dessen ist <xsl:apply-templates select="*" /> einzufügen.
- Nach dem schließenden Tag von <xsl:template match="/"> ergänzen Sie die eigene Bezeichnung, die dann in der Liste auch erscheint:
<xsl:template match="b:StyleName">
<xsl:text>My BibStyle</xsl:text>
</xsl:template>.
Bislang war ich der Meinung, dass die Benutzung von "qualified names" bei der Ribbon-Anpassung vor allem den Sinn hat, verschiedenen Add-Ins die Möglichkeit zu geben, ihre Anpassungen zu "mergen".
PowerPoint hat mich, wie so oft, eines Besseren belehrt. Die Verwendung eigener Namensräume in der customUi-Datei für VBA-Add-Ins ist zumindest dann nahezu zwingend, wenn Controls, die ihren Code aus dem Add-In holen, eingesetzt werden. Haben diese statt der IdQ nur eine Id, so reicht eine Berührung mit der Maus, um ohne weiteres Zutun eine Reihe installierter VBA-Add-Ins, die noch nicht geladen wurden, automatisch zu laden.
Da das ein eher störendes Verhalten ist, war mein erster Gedanke: Be qualified.
Aber: Oh, Schreck. Mit einer IdQ versehene Buttons finden ihre onAction-Prozeduren nicht.
Das ist auch bei COM-Add-Ins der Fall, die MSDN-Artikel verweisen hier darauf, dass der Namespace mit der ProgID identisch sein soll. Eine Sache, die ich erst nach einigen Tests verstanden habe. Verschiedene Add-Ins nutzen einen gemeinsamen Namensraum für gemeinsame Tabs oder Groups, jedes einzelne jedoch einen eigenen Namensraum für eigene Callbacks.
Allerdings: Was nützt mir dieser Hinweis für VBA-Add-Ins, was ist hier die ProgId?
Und noch eine Beobachtung: Werden dokumentbezogen quualified names eingesetzt, führt das dazu, dass der angepasste Ribbon bei allen Dokumenten und nicht nur dem, welches den Ribbon mitbringt, zu sehen ist. Auch nicht schön. Aber nicht tragisch, da es in diesem Fall sicher wenig zu "mergen" gibt.
Jens Häupel hat in seinem Blog ein Beispiel für die Übersichtlichkeit beim programmatischen Erstellen von XML-Dokumenten mit LINQ To XML gezeigt. Für den VB-Programmierer sind es ein paar Tastenanschläge mehr, aber man kann sich dran gewöhnen. Folgender Code erzeugt einen gültigen Part zur Verwendung als Spreadsheet:
Bislang war ich der Meinung, der Umstieg auf VSTO ist auch und vor allem Sicherheitsaspekten und der Trennung von Dokument und Code zuzuschreiben. Um so erstaunter stelle ich fest, dass Orcas die Möglichkeit bietet, im VBA-Code auf die Prozeduren dokument-basierter Assemblies zuzugreifen. Sie ist also wieder spannend, die Zukunft von VBA. Ob's am so genannten Vertrauensstellungscenter von Office 2007 liegt?
Gelegentlich kann man schon verzweifeln. Beim Anpassen der Zwischenablagegruppe (GroupClipboard) des Excel-Ribbons wollte es nicht gelingen, den als toggleButton ausgewiesenen Formatpinsel (FormatPainter) zu platzieren:
Bis die Erleuchtung kam: Man muss hier als Typ control einsetzen, welches den toggleButton clont und so vermutlich dessen Funktionalität (die nicht simple ist, wegen des möglichen Doppelklicks etwa) bewahrt.
Bei der Beschäftigung mit Performance-Steigerungen (angeregt duch den schönen Artikel von Charles Williams) sind mir alte Mathematik-Erfahrungen wieder eingefallen. Wie war das doch gleich mit dem Newton-Verfahren zum Bestimmen der Quadratwurzel?
Da Excel auch iterieren kann (Extras/Optionen/Iteration) und so Zirkelbezüge ausnahmsweise mal zielbringend eingesetzt werden können, muss man nur noch die Division durch Null vermeiden:
Endlich habe ich mal etwas Zeit gefunden, um den CASPOL-Einstellungen bei der Verteilung von Lösungen die mit VSTO gemacht wurden, die nötige Aufmerksamkeit zu widmen. Drei Versuche kamenin Frage, die alle CustomActions des Installer-Paketes nutzen:
1. Man schreibt eine kleine befehlszeilenorientierte Anwendung, der man Argumente in den Eigenschaften der CustomActions mit gibt. Diese führen Batch-Dateien aus, die caspol.exe aufrufen.
2. Man verwendet vbs-Scripte, die CreateObject mit "Wscript.Shell" und mit deren Run-Methode caspol.exe aufrufen. Solche Scripte werden von Norton AV als "sehr gefährlich" eingestuft, andere Programme verweigern wohl sogar die Ausführung ohne Nachfrage.
3. Man fügt dem VSTO-Projekt eine Installer-Klasse zu, deren Install-, Commit-, Rollback und UnInstall-Methoden überschrieben werden (die MSDN gibt Auskunft). Und in diesen Methoden verwendet man System.Diagnostics.Process.Start zum Aufruf der Batch-Dateien, die ebenfalls mit installiert werden. Um die Problematik des Installationspfades zu umgehen, bekommt die zu installierende Assembly einen starken Namen. Den öffentlichen Schlüssel übergibt man caspol.exe in der Batch-Datei. Man kann caspol.exe anstatt der Batch-Dateien natürlich auch direkt aufrufen, Parameter in eine config stecken und anderes mehr (etwa Klassen des Namensraums System.Security nutzen, was wohl in Zusammenhang mit dem Installer die eleganteste Art ist).
Soweit so gut. Auf dem Zielrechner erschien nun die Fehlermeldung
Installertypen können nicht abgefragt werden bzw.
Unable to get installer types
was ich zunächst auf die Installer-Klasse geschoben habe. Aber nicht doch: Wer VSTO benutzt, muss natürlich auch deren Laufzeit ins Installer-Paket stecken bzw. das Vorhandensein checken lassen (Download von vstor.exe) ...