Wie DDE-Kommunikation programmieren?

[Marsman]

Hallo!

Ich rufe aus RPG mittels RUNRMTCMD MS Word auf und übergebe per IFS-Datei einige Daten, die in das Dokument eingemischt werden. Nun habe ich davon gehört, dass man auch mittels DDE und DTAQs Daten an Office-Programme übertragen und sogar darüber eine Antwort erhalten kann. Wie programmiert man denn sowas? Was muss dazu auf dem/den PCs eingerichtet werden? Hat da jemand mal eine kurze Auflistung oder nen entsprechenden Link im Internet? Oder spricht generell was dagegen? Ich finde die Technik eigentlich recht interessant.


Titus

[Fuerchau]

DDE (Dynamic Data Exchange) ist die Uralttechnik, die zu Windows3.x-Zeiten eingeführt wurde und die denkbar schlechteste Variante in der heutigen Zeit.
DDE beschränkt sich ausserdem auf Programme, die rein auf der Windowskiste laufen und Fenster (eben Windows) enthalten.
Die Anzahl der verfügbaren Schnittstellen ist äusserst gering !
Per RUNRMTCMD geht da nix.

Das neue Verfahren heißt nun "Automatisierung" mittels COM-Objekten. Auch dieses beschränkt sich auf die Windowswelt.

Wenn du eine Kommunikation zwischen Word und AS/400 benötigst, sollte dies über ein VBA-Programm (Word-Makro) oder ein direktes PC-Programm und COM-Automatisierung gelöst werden.

[Marsman]

...ach, ich hatte mir schonfest gedacht, dass ich wegen dem DDE jetzt Schläge kriege. Nagut, dann lass ich das. Aber was ist COM?

Ich hatte (bezogen auf einen älteren Beitrag hier im Forum) auch schon damit geliebäugelt, ODBC und SQL zu verwenden. Das erschien mir aber, um nur ein paar Felder in einem einzigen Datensatz zu senden bzw. zu empfangen, etwas oversized. Außerdem mache ich mir da sorgen um die Performance. Nicht alle Kunden haben Gigabit-LAN und neueste Rechner. Hat da jemand Erfahrungen mit gemacht?


Titus

[Fuerchau]

Die Auflösung von COM kenn ich jetzt nicht (irgend was mit ObjektModel).
Im Wesentlichen basiert COM auf sogenannten Klassen mit Eingenschaften und Methoden für bestimmte Aufgaben.
Man kann auch eigene COM-Objekte erstellen (in Java gibts was ähnliches).

Was die Performance von SQL angeht, so ist das immer wieder ein heißes Thema hier im Forum, aber wenn man alles richtig macht (wer kann das schon) läufts eigentlich wie geschmiert.

Was nun deine Word-Geschichten angeht, so weiß ich nicht was du tun willst.
Mit der Serienbrief-Funktion kann ich z.B. relativ einfach ODBC-Quellen anzapfen umd die Inhalte dann als Felder in das Worddokument automatisch übernehmen.
Wobei ein Serienbrief auch durchaus nur 1 Datensatz beinhalten kann.

[Marsman]

Es geht darum, automatisch aus einer iSeries-Anwendung heraus ein Word-Dokument zu erzeugen. In das Dokument sollen einige Daten (Kd-Nr. usw.) eingestellt werden. Der Anwender braucht dann in Word nur noch den weiteren Text eintragen und das Dokument speichern. Aus der Anwendung heraus sollen die Dokumente natürlich auch verwaltet oder mit MS Word gedruckt werden können.

Das klappt soweit auch schon. Nur das ich bisher die Daten per IFS-Datei vom RPG-Programm an das Word-Makro übertrage. Da hier jeweils ein Objekt beim Senden und beim Empfangen erstellt wird, ist die Geschwindigkeit nicht optimal. Außerdem gibt es leicht mal Probleme im Multiuser-Betrieb. Deshalb suche ich nach einer besseren Methode.

Titus

[KM]

Hallo Titus,

wir hatten mal sowas mit Java realisiert. Und zwar gibt es im Jakarta-POI Projekt den Teilbereich HWPF. Mit diesen Klassen kann man das machen. Wir haben z.B. ein neues Word-Dokument damit geöffnet, die Kundenadresse vorbelegt und das Dokument dann unter einem bestimmten Namen gespeichert, sodass der Benutzer nur noch seinen Text dazu erfassen musste. Das HWPF besitzt allerdings nicht viel Funktionalität und wird inzwischen leider auch nicht mehr weiterentwickelt. Es soll irgendwann mal einen Nachfolger geben. Das ist allerdings noch ziemlich ungewiss.

Gruß,
KM

[Marsman]

Hallo KM,

danke auch für deine Tipp. Ich habe mich nun inzwischen entschieden. Ich habe mir die Datenübertragung mit ODBC und Microsoft DAO aufgebaut. Das Funktioniert bis auf eine Kleinigkeit schon recht gut.


Titus

[Fuerchau]

Die ADO-Funktionen sind einfacher und flexibler.

[Marsman]

Die ADO-Funktionen sind einfacher und flexibler.

Wo ist dabei der Unterschied? Ich habe beide Namen in der Online-Hilfe schon gelesen, weiß aber nicht, wo der Unterschied sein soll. Ich habe folgenden Code, um Daten zu lesen:

 
Private Function getConfig(ByRef cfg As Config, ByRef user As String) As Integer
 
	Dim ws As Workspace
	Dim db As Database
	Dim rs As Recordset
	Dim strConnection As String
	Dim sqlStmt As String
 
	Dim fldName, fldValue As String
 
	getConfig = 0
 
	Set ws = DBEngine.Workspaces(0)
	Let strConnection = "ODBC;DSN=UDS"
	Set db = ws.OpenDatabase("", False, False, strConnection)
	Let sqlStmt = "SELECT * FROM UDSSMSW WHERE USER = '" & user & "'"
	Set rs = db.OpenRecordset(sqlStmt)
	If Not rs.EOF Then
		cfg.feld = rs!FELD
		/* Weitere Felder */
	Else
		getConfig = 10
	End If
	Set rs = Nothing
	Set db = Nothing
	Set ws = Nothing
 
End Function

Titus

[Fuerchau]

Rein programmtechnisch eher gering wenn man nicht alle Möglichkeiten ausschöpfen muss.