Office-PlugIn mit Libre- bzw. Openoffice nutzen?

[Panther45]

Hallo,

ich würde gern das praktische Office-Plugin für Doc-Dateien auch auf Systemen nutzen, auf denen nicht MS-Office, sondern eine freie Office-Version installiert ist.
Zunächst habe ich einfach die MS-Office Konverter in
"\Program Files (x86)\Common Files\microsoft shared\TextConv\"
belassen bzw. dorthin kopiert. Damit funktioniert es ohne installiertes MS-Office nicht mehr. Die freien Office-Versionen hinterlegen im o.g. Verzeichnis leider keine Konvertermodule. Welche Dateien von diesen Versionen muss ich kopieren oder samt Pfad in die office.ini eintragen, damit das Office-Viewer-Plugin auch mit Libre- und Open-Office funktioniert? Word-Dokumente genügen mir, für Excel-Tabellen verwende ich excellence und hoffe, es wird in Bälde auch das xlsx-Format lesen können.

[milo1012]

Bevor du dich mit Text- und Dokumentkonvertern herumquälst und dir mit dutzenden Type- und CLSIDs die Registry vollstopfst würde ich dir uLister empfehlen.
Es geht doch nur um die Anzeige von Dokumenten, oder?
Einziger Nachteil bei uLister: du musst dich für das Framework von Oracle registrieren (allerdings kann man auch eine freie Version zum Download auch so im Netz finden, aber eine konkrete URL gebe ich jetzt mal lieber nicht raus) und du musst die Dateitypen die geöffnet werden sollen selbst in die ulister.ini eintragen, damit nicht alle Dateien im uLister geöffnet werden.

Wenn du trotzdem mit deinen Konvertern arbeiten willst ist die Frage auch nicht einfach zu beantworten da jede Office-Version andere Konverter mitbringt. Und wie erwähnt, mit einfachem kopieren ist es nicht getan, die Filter müssen immer registriert sein, sonst kann sie kein Programm nutzen. Wenn du Office deinstalliert hast sind auch die Registry-Einträge weg und die Filterdateien nützen halt nichts mehr.

[Panther45]

Bevor du dich mit Text- und Dokumentkonvertern herumquälst und dir mit dutzenden Type- und CLSIDs die Registry vollstopfst würde ich dir uLister empfehlen.

Danke.

Es geht doch nur um die Anzeige von Dokumenten, oder?

Ja, schnelle Anzeige, ohne Bearbeiten, möglichst mit der F3-Taste des Commanders.

Einziger Nachteil bei uLister: du musst dich für das Framework von Oracle registrieren (allerdings kann man auch eine freie Version zum Download auch so im Netz finden, aber eine konkrete URL gebe ich jetzt mal lieber nicht raus) und du musst die Dateitypen die geöffnet werden sollen selbst in die ulister.ini eintragen, damit nicht alle Dateien im uLister geöffnet werden.

Letzteres wäre kein Problem. Beim eben erfolgten Besuch der Oracle-Website, bekam ich zwar das License-Agreement zu sehen, durfte ein Javascript-Fenster quittieren, welches mir einen Cookie androhte, bekam aber nix zum Runterladen, keinerlei Download-Button etc. Ergo wird's wohl eine Freeware werden.

Wenn du trotzdem mit deinen Konvertern arbeiten willst ist die Frage auch nicht einfach zu beantworten da jede Office-Version andere Konverter mitbringt.

An sich ist die Doku der Office.ini verständlich und funktioniert mit MS-Office auch wie beschrieben. Die freien Office-Versionen hinterlegen leider nichts in "Common Files" und auch im Office-Programmverzeichnis fand ich bisher nichts, was wie Konvertermodul aussieht. In den Classes der Windows-Registry muss normalerweise nichts geändert werden. Dort könnte ich allenfalls herausbekommen, wie die Konvertermodule heißen, oder?

[milo1012]

In den Classes der Windows-Registry muss normalerweise nichts geändert werden. Dort könnte ich allenfalls herausbekommen, wie die Konvertermodule heißen, oder?

Ja, nur ist das Ganze ein Akt, ich hatte das schon einmal versucht...es sind dutzende Einträge allein nur für die Konverter. Hinzu kam noch eine merkwürdige Prüfung mit dem Windows Installer ob die Office-Installation komplett ist etc. p.p.
Letztendlich habe ich es dann aufgegeben. Und selbst wenn du die passenden Registry-Einträge bekommst, müsstest du auf jedem neuen Rechner ohne Office eine .reg-Datei ausführen nur um mit dem TC den Lister aufrufen zu können ?!...nein, danke, für mich ist das ein Flickwerk, vor allem weil du die Einträge dann behältst oder manuell entfernen müsstest.
Mal abegesehen davon dass du wahrscheinlich sowieso gegen mehrere Punkte der Office-EULA verstößt wenn du eine Office-Komponente/Dateien ohne Kernprogramm auf einen Rechner lädst

Deswegen kann ich nur noch einmal uLister empfehlen.
Was das und "Oracle Outside In Technology" angeht: hier dem Lizenzvertrag zustimmen, unten die Datei vw-8-4-0-win-x86-64.zip aufrufen und dann halt registrieren/einloggen.

[kanu969]

Hallo,

probier doch mal das
http://www.totalcmd.net/plugring/OOoHtmlViewer.html

oder das
http://www.totalcmd.net/plugring/OOSimpleViewer.html

Wenns nur um einen schnellen Inhaltscheck geht, sollte es reichen.

kanu

[Panther45]

Hallo kanu,

den OO-Viewer hatte ich in einer älteren Version schon installiert, zum Betrachten von ODTs, solange ich noch MS-Office hatte. Dafür eignet er sich, mit dem im Readme genannten Zusatztool evtl. auch für DOCx. Die klassischen DOC-Dateien werden im Readme gar nicht aufgelistet und auch nicht mit der aktuellen Version des OO-Viewers angezeigt. Darstellung von DOCx wäre auch nicht übel, aber das geht selbst mit dem eben installierten OpenXML-ODF Translator bisher nicht.

[Panther45]

Hallo,
der gute alte Office-Viewer tut's wieder:
Zunächst habe ich im Internet die Datei vw-8-4-0-win-x86-64.zip suchen lassen, (nur) bei Oracle gefunden und nach Registrierung tatsächlich bekommen. Testweise entpackt, annoex.exe, eines der Executables aus dem SDK-Verzeichnis, ins Binary-Verzeichnis kopiert. Damit lassen sich zig Dateiformate anzeigen, weit mehr als mit dem Office-Plugin, nur halt nicht so komfortabel per F3-Taste. Ist das Verfahren mit der verschobenen EXE so gedacht oder gibt es eine "elegantere" Methode, den uLister zu nutzen, z.B. über die TC-Viewer-Config?
Später kam ich auf die Idee, die DLLs vom uLister genauer unter die Lupe zu nehmen. Die Namen vl*.dll verraten, welches Dateiformat die betr. DLL bearbeitet. Also kurzerhand <path>\vsword.dll in die office.ini des Office-Plugins eingetragen: nix passiert. Anschließend die Öffnung eines Word-Dokuments mittels F3-Taste im TC durch Process Monitor überwacht: Siehe da, die vsword.dll wird geöffnet, Pech nur, dass sie offenbar nicht als Converter taugt. Die restlichen DLLs, die in der Office.ini standen wurden nicht geöffnet d.h. das PlugIn hat sie nicht mehr gefunden. Offenbar löscht die Deinstallation von MS-Office auch den Pfadverweis auf das Convert-Verzeichnis in den Common Files. Ergo habe ich die Konvertermodule mit vollständigen Pfaden in die Office.ini eingetragen. Damit werden *.DOCs wieder geöffnet, mit den Limits, die das olle Office-Plugin halt hat. Zum schnellen Sichten von Dokumenten genügt mir das aber. Vielen Dank an Kanu & Milu für Eure Hilfe!

[milo1012]

Zum uLister: die Installation besteht nur daraus die Dateien aus dem redist-Verzeichnis zu kopieren.
Aus der readme.txt zu uLister:

6. Installation
Download Viewer Technology: ... you need accept license and register.
And copy "redist" folder to plugin folder.

d.h. du hast dann z.B. in %COMMANDER_PATH%\Plugins\Lister\ulister
die ulister.wlx und die Dateien aus dem besagten Verzeichnis, also *.dll und *. flt Dateien sowie cmmap000.bin und ein paar andere.
Mehr nicht! (natürlich noch die ulister.wlx in der TC-Lister-Plugin-Konfiguration registrieren)
Du brauchst weder die annoex.exe noch solltest du manuell die vs*.dll-Dateien auswählen...einfach alle kopieren.
Hinzu kommt eine manuelle Konfiguration der ulister.ini. (sollte am besten im gleichen Verzeichnis stehen wie die ulister.wlx, kannst du aber später konfigurieren)
Hier meine ini-Datei für die meisten Office-Formate ohne PDF und Bilder und sonstige nicht-Textformate, benutze sie mal testweise:

Code: Select all

[ulister]
noloadtypes=1999,1500,1501,1502,1503,1506,1507,1508,1509,1510,1512,1514,1515,1516,1535,1557,1559,1561,1564,1574,1588,1589,1590,1591,1599,1602,1609,1646,1700,1701,1702,1703,1704,1705,1706,1707,1708,1709,1710,1711,1712,1713,1714,1715,1716,1717,1718,1719,1720,1721,1722,1723,1724,1725,1726,1800,1801,1802,1803,1804,1813,1814,1815,1820,1821,1822,1825
nopreviewtypes=1999,1500,1501,1502,1503,1506,1507,1508,1509,1510,1512,1514,1515,1516,1535,1557,1559,1561,1564,1574,1588,1589,1590,1591,1599,1602,1609,1646,1700,1701,1702,1703,1704,1705,1706,1707,1708,1709,1710,1711,1712,1713,1714,1715,1716,1717,1718,1719,1720,1721,1722,1723,1724,1725,1726,1800,1801,1802,1803,1804,1813,1814,1815,1820,1821,1822,1825
keepinmemory=1
optionsdir=%COMMANDER_PATH%\Plugins\Lister\ulister

Das uLister-Plugin sollte dann noch möglichst weit oben in der Pluginliste stehen um anderen Plugins nicht den Vorzug zu geben.

Was die Konfiguration angeht: Rechtsklick ins Viewer-Fenster.
Dort hast du dann Ansichtsoptionen!

[Panther45]

Hallo,

nach einigem Suchen habe ich dLister.wlx schließlich gefunden, bei
http://www.ghisler.com/plugins.htm
ist die ja leider nicht gelistet, sondern nur hier:
http://www.totalcmd.net/plugring/oilister.html

Milo schrieb:
>die ulister.wlx und die Dateien aus dem besagten Verzeichnis, also *.dll und *. flt Dateien sowie cmmap000.bin und ein paar andere.

Ich hatte die Oracle-Componenten zunächst ins das Verzeichnis geschoben, wo das Plugin liegt (..\ulister\ ) . Funktionierte nicht. Ergo habe ich entsprechend uLister-Readme "Copy "redist" *folder* to plugin folder" ein Unterverzeichnis "redist" wie im Original angelegt und das ganze Oracle-Geraffel dorthin vergeschoben. Auch nicht besser.
uLister.ini habe ich mit den gleichen Ausschlüssen konfiguriert wie von Dir vorgegeben. Damit werden wohl Grafiken, Musik, Filme etc. weitgehend ausgeschlossen. Das entspricht auch meiner Intention (dafür habe ich IrfanView). Laut PlugIn-Manager ist uLister.wlx aus dem korrekten Verzeichnis geladen und mit "Configure" wird die uLister.ini geöffnet. Die Plugin-Pfade scheinen also zu stimmen, nur der Qracle-Krams wird wahrscheilich nicht gefunden. In der Viewer-Reihenfolge steht uLister nach dem Fileviewer, aber vor Office- OO- und html-Viewer. Trotzdem benutzt der TC-Viewer die bisherigen Komponenten, z.B. für Word-Dokumente. uLister kommt also nicht zum Zuge. Ähnlich verhält sich aber auch das Office-Plugin, wenn es die benötigten Konverter-DLLs nicht findet. Muss wohl nochmal der Process-Monitor ran.

[milo1012]

Tja, ist normalerweise relativ problemfrei.
Entscheidend ist die Haupt-DLL sccvw.dll, wenn die nicht im gleichen Verzeichnis liegt wie die ulister.wlx funktioniert nix, die restlichen DLLs werden dann bei Bedarf geladen.
Ich habe vorhin nochmal testweise eine Installation gemacht, lief problemlos.
Du solltest natürlich auch die gleiche Verzeichnisstruktur nehmen wie in der ulister.ini steht, also entweder Verzeichnisse ändern oder die Ini ändern.
Ansonsten die übliche Vorgehensweise bei störrischen plugins: alle anderen plugins probeweise deaktivieren (vorher Backup der Commander-Ini) falls diese dazwischenfunken.

[Panther45]

Process Monitor verrät mir:
Gesucht wird:
%COMMANDER_PATH%\PlugIns\uLister\sccfi.dll
Gefunden wird schließlich:
%COMMANDER_PATH%\PlugIns\uLister\redist\sccfi.dll
Das Verlagern der Oracle-Komponenten ins redist-Verz. scheint also kein Problem für das Plugin zu sein.
Weitere DLLs werden nicht abgefragt. Nebenbei habe ich aber festgestellt,
dass msvcr80.dll fehlte. Die EXE aus dem SDK funktionierte ohne, die braucht diese DLL anscheinend nicht. Was ich auf die Schnelle im Internet
fand ist msvcr80.dll v8.00.50727.42 von 2005, also schon etwas alt. Bringt's aber auch nicht.
Eben habe ich entdeckt, dass uLister mit TC64 läuft. Demzufolge habe ich die 64Bit-Version der Oracle-Komponenten erwischt.
Gips die auch 32Bittig? Auf der Oracle-Site fand ich nur einen Link. Der Name des zip-Archivs,
vw-8-4-0-win-x86-64.zip, verrät auch nicht wirklich, ob es 64Bit-Software ist oder 32Bit oder beides.

[milo1012]

Wird ja immer komplizierter
Zunächst verstehe ich jetzt endlich dein ursprüngliches Problem.
Im verlinktem uLister-Thread ist das Plugin offenbar selbst nicht zum Download verlinkt, aber da ich als Alternative zum Office-Plugin sprach bin ich davon ausgegangen dass du zuerst das Plugin selbst lädst.
Auf totalcmd.net finden sich ja praktisch alle Plugins, aber hat sich ja jetzt erledigt.

Zum neuem Problem: ich benutzte prinzipiell nur 32bit-TC und demnach auch Plugins, mit 64bit habe ich es nie probiert. Und ja, im vw-8-4-0-win-x86-64.zip-Archiv sollten eigentlich beide Architekturen zu finden sein.
Ich benutze allerdings ein anderes Paket wo klar nach 32bit und 64bit unterschieden wird.
Schau mal ob du im Archiv Unterverzeichnisse wie x64 oder x86 hast und probiere es dann mit 32bit, ansonsten kann es ja nicht funktionieren...allerdings wird die sccfi.dll geladen, also so falsch kann das Paket nicht sein.

Zur schnellen Ansicht ob eine DLL 32/64bit ist gibt es z.B. das TC-Plugin fileinfo, auch hier zu finden.
Vorgehen: auf Image File Header gehen und dann unter FILE HEADER->Machine findest du die Architektur.
Wenn das nicht hilft gebe ich doch den Link raus mit den Dateien die definitiv bei mir funktionieren, aber eigentlich sind es die gleichen wie beim offiziellem Download...

Die msvcr80.dll wird leider benötigt, aber keine weitere VC-Runtime, d.h. ein einfaches kopieren ins gleiche Verzeichnis sollte genügen.
Guter Punkt, ist mir nie aufgefallen da ich die Runtimes immer installiert habe.

Du solltest übrigens trotzdem alle DLLs ins gleiche Verzeichnis kopieren
...wenn du ein Unterverzeichnis nutzt ist nie garantiert ob es irgendwelche Rücksprünge zum Plugin gibt
...relative Pfade sollten eigentlich vermieden werden, habe da schon die tollsten Kuriositäten erlebt.




Nachtrag:
Scheint doch so zu sein dass man die Visual C++ Runtimes in der 2005er-Version braucht, ein einfaches kopieren der msvcr80.dll reicht nicht.
Für XP auf alle Fälle, für Vista und Win7 bin ich nicht ganz sicher ob sie schon enthalten sind.
Deswegen hasse ich kleinere und mittlere Programme die nicht statisch linken.
Bei heutigen Plattengrößen gibt es kaum noch einen Grund für mäßig große Programme auf externe Runtimes angewiesen zu sein. (Stichwort DLL-Hell)

[Panther45]

Milo wrote:

Zum neuem Problem: ich benutzte prinzipiell nur 32bit-TC und demnach auch Plugins, mit 64bit habe ich es nie probiert. Und ja, im vw-8-4-0-win-x86-64.zip-Archiv sollten eigentlich beide Architekturen zu finden sein.

Nee, das ist entgegen dem Namen nur die 64Bit-Version. Die 32-Bit-Variante hatte ich aber auf der Website von Oracle übersehen und
inzwischen nachgeladen. Funktioniert auch.

Zur schnellen Ansicht ob eine DLL 32/64bit ist gibt es z.B. das TC-Plugin fileinfo, auch hier zu finden.

Das habe ich, allerdings bisher noch nie eindeutige Unterschiede zwischen 32- und 64Bit-Komponenten feststellen können!
Die Oracle-Entwicklar waren aber so freundlich, das deutlichst in ihren Komponenten zu vermerken.
Außerdem von Dir der entscheidende Tip:

Vorgehen: auf Image File Header gehen und dann unter FILE HEADER->Machine findest du die Architektur.
Wenn das nicht hilft gebe ich doch den Link raus mit den Dateien die definitiv bei mir funktionieren, aber eigentlich sind es die gleichen wie beim offiziellem Download...

Vielen Dank, das ist genau das Unterscheidungsmerkmal, was ich schon lange suche.

Die msvcr80.dll wird leider benötigt, aber keine weitere VC-Runtime, d.h. ein einfaches kopieren ins gleiche Verzeichnis sollte genügen.
Guter Punkt, ist mir nie aufgefallen da ich die Runtimes immer installiert habe.

32bittig habe ich msvcr80.dll zu den Oracle-Komponenten dazugepackt.
Ob sich im Internet eine 64Bit-Version auftreiben lässt, muss ich noch schauen.
Ich habe die 32er und die 64er Version vorerst in getrennten Verzeichnissen installiert. Ob es so möglich ist, beide Versionen zu nutzen, gilt es noch zu testen.

Du solltest übrigens trotzdem alle DLLs ins gleiche Verzeichnis kopieren
...wenn du ein Unterverzeichnis nutzt ist nie garantiert ob es irgendwelche Rücksprünge zum Plugin gibt
...relative Pfade sollten eigentlich vermieden werden, habe da schon die tollsten Kuriositäten erlebt.

Vorerst lasse ich es der Übersichtlichkeit halber wie es ist. Sollten Probleme auftreten, kann ich die Oracle-Komponenten jederzeit nach ..\ verschieben.

Nachtrag:
Scheint doch so zu sein dass man die Visual C++ Runtimes in der 2005er-Version braucht, ein einfaches kopieren der msvcr80.dll reicht nicht.
Für XP auf alle Fälle, für Vista und Win7 bin ich nicht ganz sicher ob sie schon enthalten sind.

Auf meinem W7-System ist C++ 2005..2010 installiert. Wahrscheinlich deswegen funktionierte die 64Bit-Version, obwohl keine 64bittige
msvcr80.dll im redist-Verzeichnis vorhanden war.
Auf dem Home-PC funktioniert das nämlich nicht, evtl. ist dort C++ nicht installiert.
Nach Installation von uLister32 funktioniert TC64/uLister64 nicht mehr.
Mit der Koexistenz isses also nicht ganz so einfach.
Ist aber nicht gar so tragisch. Sobald die wichtigsten Plugins 64bittig und
zuverlässig verfügbar sind, wird halt auf TC64 umgestiegen.

[milo1012]

Ja, Sorry, ich hatte die falsche Datei verlinkt und hätte vielleicht gleich klarstellen sollen das es die 64- und 32bit-Varianten gibt.
Das kommt davon dass ich ein anderes Archiv benutzte...
Jedenfalls gibt es für jede VC-Runtime eine 64bit-Variante.
Für die 2005er-Version z.B. hier, nur ist es mit dem einfachen kopieren der Dateien halt nicht getan, das Paket muss installiert werden.
(vermutlich wegen dieser Side-by-side-Assembly-Geschichte)

Um nochmal klarzustellen:
Du kannst 32- und 64bit-DLLs nicht beliebig mischen.
Eine 64bit-Anwendung (also auch Total Commander 64bit) braucht ausschließlich 64bit-DLL's bzw. 64-bit-Code,
eine 32bit-Anwendung ausschließlich 32bit-DLLs, ein Mischen funktioniert nicht und wird auch nie funktionieren.
Siehe dazu auch hier.
Dementsprechend brauchst du auch 64-bit-VC-Runtimes, aber die sollten auf 64-bit-Windows eigentlich sowieso installiert sein.

Hast den uLister denn nun zum Laufen gebracht? (egal welche Variante)
Ich finde es jedenfalls ärgerlich dass nirgendwo auf der Oracle-Seite oder in der Doku vermerkt ist dass die Runtimes benötigt werden.
Nun ja, jetzt sind wir schlauer.

[Panther45]

Wie bereits geschrieben, die 32Bit-Version des uListers läuft momentan.
Inzwischen konnte ich office.wlx, excellence.wlx und auch htmlView.wlx deinstallieren, uLister ist weit mehr als nur Ersatz.
Einige Ausschlüsse aus Deiner INI-Datei habe ich gestrichen, so dass jetzt auch PDFs und zip-Archive angezeigt werden.
Letzteres ist freilich mehr schön als nützlich.
Dass sich 32- und 64Bit-Komponenten nicht mischen lassen, ist klar.
Problem war anfangs, dass ich die DLL aus C++ nur 32bittig auftreiben konnte.
Die 64Bit-Version habe ich schließlich in %WINDIR%\winsxs\amd64...\ gefunden und ins redir64-Verzeichnis kopiert.
Zu den zigtausend Verzeichnissen unter winsxs gibt es keine Pfade, deshalb wird die DLL offenbar nicht gefunden.
Laut Application Wizard sind die C++ Komponenten ja installiert.
Momentan läuft die 64Bit-Version des uListers zwar noch nicht, aber das hebe ich mir für später auf.
Mit Reinstallieren des uListers in einem Verzeichnis, wo die VW840x64-Komponenten liegen, müsste sich das zumindest "umschalten" lassen.

In der Oracle-Doku steht übrigens drin, dass C++ benötigt wird (c02_windows.html und im PDF):
"This product requires the Visual C++ libraries included in the Visual C++ Redistributable Package available from Microsoft.
There are three versions of this package (x86, x64, and IA64) for each corresponding version of Windows."

Die wichtigste scheint aber wirklich die msvcr80.dll zu sein. Sobald die vom uLister gefunden wird, funktioniert er.
msvcr80.dll ihrerseits enthält nur Verweise auf kernel32 und msvcrt.dll.