🚀 go-pugleaf

"Stefan Werner" <009wcqf02@sneakemail.com> a �crit dans le 
message de news: 4a216ca4$0$9114$5402220f@news.sunrise.ch...

<...>
>> c) ihre interne Anwendungen m�ssen sie nicht ver�ffentlichen. 
>> Bsp.
>> Fachanwendungen, Archivierungen, eigene Formate, etc.
>
> Die m�ssen si aber ermutlich teilweise mit erheblichem Aufwand 
> auf Windows bzw. OpenOffice portieren. VisualBasic oder 
> WorBasic-Anwendungen sind gar nicht mal si einfach zu 
> portieren. Dasselbe gilt f�r komplexere Excel-Anwendungen. Ich 
> gehe mal davon aus, dass die meisten internen Anwendungen ehr 
> so Applikationsorientiert sind und kaum in Java oder C++ 
> programmiert sein werden...

W�hrend wir schon 1990 locker Office Automation zwischen Word 
2.0, einer in C geschriebenen Kundenapplikation und mit SQL 
Server demonstrieren konnten, ist dasselbe auch heute noch mit 
OpenOffice einfach zum M�use melken.

Es ist eben nicht damit getan, dass man einen Text von Hand 
schreibt und dann korrekt drucken kann, sondern das Ganze muss 
automatisiert werden k�nnen. Daf�r ben�tigt es einfache 
Schnittstellen, so wie es diese bei Microsoft praktisch seit 
Anbeginn von Windows gibt (COM, DDE, etc) - und dazu eine 
einfachste Scriptsprache (damals Wordbasic, dann VBA etc), mit 
welcher auch ein Hobbyprogrammierer Daten herumschieben kann und 
den Output selber gestalten und trotzdem automatisieren kann.

Nun versuche man das mal bei OpenOffice mit UNO etc... das ist 
zum Schreien. Schade eigentlich, denn ich w�rde ansonsten 
OpenOffice sofort gegen MS Office 2007 eintauschen (Denn bis ein 
auf MS Office 2003 geschulter Anwender die Version 2007 bedienen 
kann, fliesst mindestens soviel Geld, wie bei einer Umschulung 
auf OpenOffice!).

Aber eben: Office Automation. Da happerts deutlich bei 
OpenOffice.

Wen's interessiert, wie das theoretisch mit UNO realisiert werden 
soll, kann mal diesen Artikel (und auch Teil 2) studieren:
http://www.linuxjournal.com/article/8550