Mal eine Frage an das Hohe Haus:

Vor einigen Wochen bin ich von Office 2007 auf Office 2010 umgestiegen, und mein Drache mit mir. Letzteres will heißen, entgegen meinen ursprünglichen Befürchtungen funktionieren auch die Befehle, die ich mir für Office 2007 unter Einbindung der entsprechenden Objektbibliothek gebastelt hatte, eigentlich anstandslos unter Office 2010.

Offenbar hat Dragon automatisch beim Umstieg die Befehle auf die neuen Objektbibliotheken aktualisiert. Wenn ich mir nämlich dort mit „Alt Enter“ die eingebundenen Referenzen anzeigen lasse, finde ich auch einen Verweis auf die entsprechende Bibliothek für Office 14.
Unmittelbar in der Zeile darunter finde ich eine Angabe "Bad Reference" mit einem Verweis auf die entsprechende Bibliothek für Office 12 (also Office 2007). Da denkt man sich – logisch, die wird ja wohl auf dem System nicht mehr vorhanden sein, weil Office 2007 bei der Installation von Office 2010 automatisch entfernt wird.
Das Erstaunliche nun: wenn ich die „böse Referenz“ deselektiere, erhalte ich beim Speichern sofort einen Syntaxfehler, obgleich die richtige Referenz auf Office 14 noch gesetzt ist. Das passiert bei jedem derartigen Befehl, so dass ich nicht vermute, dass es mit einer Bezeichnung eines Objekts unter Office 2007 zu tun hat, die es unter Office 2010 nicht mehr gibt, sondern etwas Allgemeineres die Ursache ist.

Kann mir das jemand erklären?

Marius Raabe

Hohes Gericht, Herr Vorsitzender,

darf ich eine Vermutung äußern, und das Material zur vollständigen Beweisführung ggf. später nachliefern? -

Zunächst, als ich mit Dir mal eine Zeitlang Skripte hin- und hergeschoben habe (bei Dir von Office 2007 zu Office 2010 bei mir, was ich dann aufgegeben habe, wegen dauernder Probleme damit, und zu Office 2007 virtuell gewechselt bin), habe ich mal etwas ähnliches beobachtet. Wenn Du Dir den genauen Dateinamen unter "Location" ansiehst, wirst Du sehen, dass die Erweiterung "olb" lautet, die man für gewöhnlich nicht im Programm-Ordner antrifft. Also auch eine solche Datei nicht, die es aber bei Dir nun geben muss.

So, jetzt kommt die Vermutung, für die es aber eine Indizienlage gibt, die mehr als den Anfangsverdacht rechtfertigt, wenn Du mich fragst. Die Erweiterung steht für "old library", im Normallfall lautet die Erweiterung "dll" (dynamic link library). Weiterhin nehme ich an, dass die "old library" ein Produkt der Konvertierung des Skriptes ist, und der Verweis darauf notwendig, weil da etwas drin steht, was für das Skript von Bedeutung ist, oder auf jeden Fall kann es ohne dem nicht leben.

Langer Rede, kurzer Sinn: wie Du Dir denken kannst, bin ich kein Freund von halbem Kram, wenn es um Essentielles geht. Ich würde die Skripte nicht konvertieren, sondern neu anlegen, mit korrekter Referenzierung.

Gruß, Rüdiger

Zitat von R.Wilke

---

Hohes Gericht, Herr Vorsitzender,

---

Zu viel der Ehre (und zu wenig der FXXXXXXX/des GXXXXX), großer Meister! {zensiert, W.S.}

Zitat von R.Wilke

---

Also auch eine solche Datei nicht, die es aber bei Dir nun geben muss.

---

Selbstredend habe ich in dem bezeichneten Ordner nachgeschaut, dieser ist jedoch bis auf zwei (diesbezüglich unverdächtige) Unterordner leer, enthält jedenfalls nicht die olb-Datei.

Es rätselt weiter, Marius

Na, dann ist es eben ein Artefakt, ein Ding der dritten Art, oder einfach nur ein Fehler in der Matrix.

Dr. Spock

Hello Marius, long time no speak unfortunately

could you try something for me?

Create a new command with a different name to one of these existing converted scripts.

Set the reference to the object 14.0 Microsoft Outlook Office10 library

Copy the contents from one of the converted scripts to this new command/script

then run this new command.

If it works, which I think it will, it discounts the different object name theory and points to a fifth dimension Dragon mapping situation which I would normally need 14 pages to describe. However for one with unbound intelligence, such as a forum moderator, the old bad reference (so-called) is just a mapping of objects between the old object library and the new one.

If it doesn't work then the different object name (or something akin to this) theory has grown new legs.

Lindsay
www.pcbyvoice.com

Hey Lindsay, good to read from you - you still in FL or back home?

Yes, it works as expected - fith dimension, here we come! Since the the "converted" scripts work as well for Office 2010 as new ones do, I am just too lazy to re-create all the scripts... Anyway, this makes me marvel again at the complexity of IT in general and Dragon in particular.

MDH

Good to hear from you too as always. Back in UK and sensible temperatures and humidity.

So basically the little experiment shows that the bad reference (so-called) is just a mapping (or something of that ilk) of objects from the version 12 object library to the version 14. You need it checked otherwise the scripts won't know to use the version 14 objects instead.

I wouldn't be bothered either replacing all of your converted scripts with new ones.

Lindsay
www.pcbyvoice.com

Quite a funny way of mapping, isn't it - pointing to a seemingly non-existing file (on my home system, not even the folder exists). THE DRagon moves in mysterious ways to perform his wonders - mysterious at least to me

Devout M.

Marius,

have you tried exporting one of the converted scripts in XML format? I am just asking because sometimes the XML text contains additional information. According to a quick Google search for "bad reference" in VBA the fact seems not so uncommon though, and how shouldn't it, also when converting VBA macros directly across MS Office versions, however from what I have read everything should be a lot more obvious than what's happening when converting inside Dragon with external references being involved.

Converted Rüdiger

Here you go. Inconclusive, don't you think?
proselyte Marius

Zitat

---

- - OUTLOOK Microsoft Corporation Microsoft Office Outlook - -

- - -

-

-

-

-

-

-

-

-

-

-

-

-

-

- -

-

-

-

-

-

-

-

---

Well according to the one below, Late Binding is the answer to avoid any problems in the future:

http://answers.microsoft.com/en-us/offic...fc-68b599b31bf5

However, leaving things as they are is another way of handling it.

Rüdiger

Zitat von Marius Raabe

---

Quite a funny way of mapping, isn't it -

---

No it is very clear and demonstrated very well in your XML output. If you look at the XML and specifically the following number:

00062FFF-0000-0000-C000-000000000046

this is the class ID of the new Microsoft Outlook object library 14 and listed immediately afterwards is the actual location (well it was the location previously that you script still references) of the previous library (12). This is the mapping which tells the script that if it wants information from the object 12.0 library location it should now reference this information from the object 14 class ID in the registry.

The reason that the new library is listed as a class ID is because your advanced script references the registry for that class ID (search for it with the registry editor and you will see what I mean) and from the information in the registry for this class ID it gets the location of the new object library files etc and various other details as you will see in the registry.

The old object library (12.0) is no longer listed as a class ID in the registry because it is no longer installed.

Lindsay
www.pcbyvoice.com

Lindsay, thanks for pointing that out to a dummy. I am flabbergasted again.

What was that saying again?

Zitat von Lunis Orcutt

---

considered to be 1 of the world's most renowned speech recognition specialists

---

Kudos, C.R.

Marius

I wouldn't expect class IDs of COM objects and libraries to be a common discussion point among lawyers basically any script or program referencing such libraries need this class ID so as it can look up all the necessary information in the registry before it can run properly.

Apart from CR (acknowledged as one of the world's leading experts on speech recognition, really!), We must never forget the real German specialist Rüdiger Wilke and his extraordinary microphone testing skills. I am very proud to know him.

A mere Moderator

Zitat von monkey8

---

I wouldn't expect class IDs of COM objects and libraries to be a common discussion point among lawyers

---

Jurisprudentia est scientia omnium rerum, humanarum atque divinarum.

Zitat

---

... Rüdiger Wilke and his extraordinary microphone testing skills

---

.... which skills extend far beyond microphones as Rüdiger is in the process of demonstrating right now (watch out!).

Marius