Inoffizielles deutsches Xbase-Forum

Ein anderes Programm schickt mir eine Windows Nachricht (WM_USER_xxx). Wie kann ich diese Nachricht erhalten?

Ich habe es mal so versucht ob irgendetwas kommt:
Weis nicht was 1048626 ist, habe es nur ausgefiltert weil dieser Event ständig kommt. Die Nachricht die ich erhalten sollte war aber nie dabei.

Das Konzept von Xbase++ sieht vor, dass es nur "erwünschte" Events von Windows durchreicht, also jede Menge im Hintergrund abgeblockt werden.
Man kann aber selbst Ereignisse (also Events) generieren wenn man diese selbst aus der Xbase++ Anwendung sendet.
Ob das von einer an einer andere EXE geht, habe ich nie probiert.

Vermutlich müsstest du direkt die Windowsevents abfragen um deinen WM_USER_xxx Event zu erhalten.
Ich meine in der ot4xb ist eine Funktion die das kann, als Ersatz für AppEvent(@mp1,@mp2,@oXbp)

Das fragliche - gefilterte - Event dürfte das Resizing-Event sein:

http://news.alaska-software.com/readmes ... %2B%2B.gui

Wie kommt man auf die Event-Nummer ?

=> AppEvent.ch
Einfacher Weg manuell: nEvent - xbeB_Event => Wert in Tabelle suchen

1048626 - 1048576 = 50 ... also nicht resize, sondern paint

im Code der Eventschleife könnte man natürlich auch gleich die Konstanten verwenden:

brandelh hat geschrieben:im Code der Eventschleife könnte man natürlich auch gleich die Konstanten verwenden:

Hubert, man muss! Wie willst du sonst lesbaren Code erstellen?

Danke für Deine Erklärung Hubert. Darum habe ich auf die schnelle mit der Textsuche den Code 1048626 nicht gefunden.

@Herbert,
klar muss man das! Das war nur ein Versuch um beim Debuggen einen speziellen Event zu finden, was mir aber nicht gelungen ist...

@all
Wenn Xbase das aber nicht sauber handelt, wäre es eventuell eine Überlegung gleich Socktes für die Kommunikation zweier Programme zu verwenden (beides Win32 aber unterschiedliche Entwicklungssysteme)? Aber für die Sockets braucht man wieder die Professional...

Herbert hat geschrieben:

brandelh hat geschrieben:im Code der Eventschleife könnte man natürlich auch gleich die Konstanten verwenden:

Hubert, man muss! Wie willst du sonst lesbaren Code erstellen?

du hast Recht, wenn man auf den Event reagieren will, ich habe oben aber erklärt, wie man von einer ermittelten Nummer (nEvent) zu dem Eventnamen kommt. Das geht auch per Hand

satmax hat geschrieben:Ein anderes Programm schickt mir eine Windows Nachricht (WM_USER_xxx). Wie kann ich diese Nachricht erhalten?

in dem du einen Event per o:subscribeEvent() über die COM Schnittstelle "abonnierst".
nun ist ein Event nicht alles ... meistens gehören auch "Daten" dazu.

Xbase++ belegt Callback-Slots mit Codeblock und die "Daten", welche du aus C übergeben musst, kommen als Parameter zwischen den beiden "|".
mit ot4xb kannst du auch einen Callback-Slot bauen und durch den "Callback-Compiler" (xppcbk.exe ) jagen und als OBJ einbinden.

Hallo Jimmy,

Du meinst so ähnlich: Nur, woraus erstelle ich mein ActiveXObject? Was setzte ich für "xxx" ein? Ich denke da ist die USER32.dll im Spiel.

Oder liege ich da total falsch?

Jimmy's Lösung geht wohl davon aus, dass Xbase++ eine ActiveX Verbindung zu deinem Programm hat.

Ich habe das ganze jetzt mal kurz mit den Sockets angetestet, das funktioniert auf Anhieb. Wäre eigentlich die offener Lösung und würde mir mehr gefallen. Gemacht habe ich es mit den Xbase++ Socket Funktionen. Warum funktionieren die bei mir, habe ja keine professional ???

Womit ich bei der nächsten Frage wäre, Xbase++ Socket und auf professional upgraden, oder Xb2.net? Auf dem Papier sieht Xb2.net für mich etwas professioneller aus.

Für alle Socket-, Soap- oder FTP-Sachen nehme ich XB2.Net, funktioniert hervorragend und Boris leistet auch guten Support.

satmax hat geschrieben:Ich habe das ganze jetzt mal kurz mit den Sockets angetestet, das funktioniert auf Anhieb. Wäre eigentlich die offener Lösung und würde mir mehr gefallen.

wäre gut wenn du sagst "was" du machen möchtest ?

Ich versuche es:
im ersten Schritt übergebe ich einen Parameter 4711.0000 an ein anderes Programm (von uns). Dieses Programm führt nun Berechnungen durch und schreibt das Ergebnis in unsere SQL DB und schickt mir eine Nachricht fertig damit ich die Daten neu einlesen kann.

2. Möglichkeit: ich erstelle eine ASCII Datei und sende eine Nachricht an ein anderes Programm damit diese Daten verarbeitet werden, wenn dieses Programm fertig ist erhalte ich eine Nachricht.

3. Möglichkeit, ich schreibe in die SQL DB und verständige ein anderes Programm. Hier wäre es auch manchmal von Vorteil die Nachricht an einen Server zu senden (auch da läuft ein Programm von uns).

Grob und abstrakt skizziert.

satmax hat geschrieben:Grob und abstrakt skizziert.

das hört sich doch schon recht exakt an.
wenn du dich auf der Ebene bewegen willst empfehle ich dir WM_COPYDATA
anbei 2 Beispiele wie er einen externen Callback Slot bereitstellt.

p.s. mehr Beispiele gibt es bei Pablo Botella Navarro auf seiner Website http://www.xbwin.com

die Sockets waren früher in der ASINET (Prof. Sub) ab 2.00 sind die aber in der normalen Sub enthalten.
Die kannst du auf jeden Fall nehmen ohne Zusatztools.

Xb2.NET ist schon lange im Markt, viele hier schwören auf die gebotenen Funktionen, welche weit über die Prof. Sub. / ASINET hinausgehen.
Ich selbst nutze sie nicht, für eMail war mit die Asinet gut genug, mehr brauchte ich nicht.

@Danke Jimmy, da gibt's wieder viele zu lernen bei Deinen Beispielen. Das geht dann aber nur lokal und nicht auch übers Netzwerk, oder?

@Hubert
Ich bin nur etwas verunsichert weil in der Hilfe bei allen Socket* Funktionen "Professional" in der ersten Zeile steht. Muss ich wohl bei Alaska nachfragen.

satmax hat geschrieben:@Hubert
Ich bin nur etwas verunsichert weil in der Hilfe bei allen Socket* Funktionen "Professional" in der ersten Zeile steht. Muss ich wohl bei Alaska nachfragen.

da hast du Recht, aber ich habe das in einer der vorherigen Versionen unter Änderungen gelesen ... ich meine damals stand oben nicht Proffesionell ...

Aber auf jeden Fall steht unten unter Abhängigkeiten:

socket.ch
Static library
xpprt1.lib
Dynamic library
xpprt1.dll

und das ist die Basis DLL überhaupt

Hallo Hubert,

hier die Antwort von Alaska:

Die Socket Funktionen (ehemals in der asinet1c.dll) gehören zum
Professional Umfang. Insoweit ist die Dokumentation korrekt. Eine
Nutzung dieser Funktionen mit einem Foundation Produkt ist ein
Verstoß gegen die Lizenzbestimmung.

Dass die Funktionen gegenwärtig von einem Foundation Produkt
heraus nutzbar sind, hat technische Gründe die künftig beseitigt
werden.

Ich hoffe das hilft Ihnen weiter.

Mit freundlichen Grüssen,

Ich habe jetzt etwas mit WM_Copy gespielt und das funktioniert prinzipiell (dank Jimmys Beispiele). Nur muss mein gegenüber dazu sein VC++ Programm anpassen und der ist nun bis Dienstag auf Urlaub.

Warum tendiere ich nun doch wieder mehr zur Windows Message, es ist der Terminalserver, wenn ich da 30 User haben, brauche ich auch 30 Verschiedenen Ports damit sich die Sessions nicht in die quere kommen. Also müsste ich auch eine Art Portverwaltung programmieren. Außerdem müsste ich mir die Socket-Lib erst kaufen.

satmax hat geschrieben:Warum tendiere ich nun doch wieder mehr zur Windows Message ...

WM_COPYDATA ist eine Windows Message ...

Ja, das ist mir klar JImmy, durch dein Beispiel bin ich ja wieder auf WIN_MSG gekommen, ist für diesen Fall besser, den anderen Fall werde ich vermutlich mit Sockets lösen.
Ich meinte mit WM_Copy eigentlich WM_COPYDATA.

Das Beispiel TestWmCopyData.zip passt perfekt. Damit bekomme ich auch die normalen WM_USER_* Nachrichten in meinem Xbase++ Programm.

Mit einem Klick
rufe ich ein anderes Programm auf bzw. schicke nur eine WM_USER* MSG an das andere Programm,
dieses Programm führt Berechnungen durch, schreibt die Werte in die SQL DB, schickt mir eine WM_MSG das es fertig ist,
mein Programm aktualisiert die Werte aus der DB und zeigt die Daten im aktuellen Auftrag an.

Der Trick ist praktisch die CallBack Function in Verbindung mit dem via DllExecuteCall erstelltem (hidden) Windows Fenster, das nun wirklich alle Windows-Nachrichten erhalten kann. Die Vergabe und das Arbeiten mit der UUID macht zudem unabhängig vom Titel des Fensters.