... hat etwas gedauert, ich will ja keinen Mist erzählen.
--- snip ---
hab ja nie behauptet das Alaska "Starkstrom" produzieren würde.
--- snap ----
Die haben in diesem Fall mit der Stromsärke nichts zu tun, denn das ist API-Rufcode.
--- snip ---
hast du ein (verständliches) Beispiel wie man z.b. ein Outlook Attachment "in" eine Xbase++ App ziehen kann
--- snap ---
Ich habe ein Beispiel geschrieben, deswegen hat meine Antwort so lange gedauert. Aber das Thema ist etwas komplexer. Wenn Du Dich als Drag&Drop-Empfänger registrierst, dann kommen da viele bunte Sachen an und Du musst entscheiden, was Du annehmen kannst. Ob nun Outlook oder Excel oder Word oder ein anderes Programm der Ursprung Deiner Daten ist, kratzt Dich da erst mal nicht.
Außerdem kann es sein, dass nicht nur eine Mail auf Deine Anwendung geworfen wird, sondern gleich mehrere. Das gilt es zu berücksichtigen.
Wenn Du das verstanden und Dich durch die Clipboard-Formate der Office-Programme gekämpft und gegoogelt und geweint hast, dann kannst Du zu Werke gehen und Dein COM-Objekt schreiben, das ein IDropTarget Interface implementiert. Dieses muss sich dann noch mit RegisterDragDrop beim Betriebssystem registrieren.
In der IDroptarget:Drop - Methode geht es dann zur Sache: Rausfinden, was der Benutzer alles an seinem Mauszeiger hängen hat und ebendieses abgreifen, wenn es nach unserem Gusto ist. Dafür bekommt man das IDataObject Interface abgeliefert. Im E-Mail-Fall kriegen wir die Daten hieraus via IStorage Interface und im Fall, dass mehrere Mails abgeworfen werden, kann man sich ein IStorage Interface nach dem anderen abholen.
Damit hat man schon mal den Zugang zu allen Daten und bekommt sogar einen Dateinamen für die Daten geliefert, der bei einer Outlook-Mail mit ".msg" endet. Mit den Daten kann man nun was anstellen und man könnte sie z.B. in eine Datei schreiben. Das ist auch gar nicht schwer, denn man erzeugt sich einfach eine DocFile-Datei mit einem IStorage Interface und in diese kopiert man dann die Outlook-Mail-Daten locker flockig, denn IStorage bietet ja die Methode CopyTo. Welch eine Glück.
So schafft man es in nullkommanichts eine .msg-Datei aus einer gedroppten Mail zu erzeugen. Ab da müsstet Ihr mit plain vanilla Xbase klarkommen, z.b. um an den Anhang zu kommen. Das sollte aber noch viel schöner gehen mit der Funktion OleCreateFromData, aber die habe ich noch nicht erfolgreich ausprobiert.
Da Du bei dem gewünschten Beispiel das Attribut "verständlich" auf .T. haben möchtest, zeige ich es hier nicht und beantworte Deine Frage mit: "Nein, das geht nicht."
--- snip ---
und wie sieht es anders-rum aus also von einer Xbase++ App in eine andere Windows App ?
--- snap ---
Grundsätzlich kein Problem, für normale Cipboard-Formate locker, wenn man aber volles OLE implementieren möchte, könnte das wirklich Arbeit und viele Tränen bedeuten. Und da gibt es vielleicht auch Grenzen des Machbaren
--- snip ---
App = Programm
-- snap ---
Dann sag doch Programm.
--- snip ---
die meisten User in diesem Forum haben IMHO "keine Ahnung von Windows API" ... deshalb versuche ich es mit "einfachen" Worten zu erklären. ich verwende deshalb den Begriff "Windows Event Queue", im Gegensatz zur "Xbase++ Event Queue", wo sich die WM_* "Notify Events" "tummeln" die ich "abfangen" möchte um aus Xbase++ darauf zu reagieren (meistens mit Xbase++ Userdef Events)
--- snap ---
Es gibt keine "Windows Event Queue" und eine hypothetische hilft einem auch nicht. Die vielen Gänsefüßchen sind ein Indikator, dass das für Dich auch etwas nebulös ist. Ist es aber nicht. Wenn man die Fakten kennt.
--- snip ---
auch interessiert es die User meisten gar nicht was im Detail passiert ... oder (Sicherheits) Problem wenn man es "falsch" verwendet solange es "funktioniert". So stellt für mich die Kombination von FindWindowExA() / SendMessageA() mit BM_CLICK kein "Problem" da auch wenn anderen meinen es wäre "schlechtes Benehmen".
sicherlich ist es eleganter per TAPI ein FAX zu versenden aber im Grunde reicht es die Rufnummer, per WM_SETTEXT, in das Eingabe Feld des Dailer zu bringen und den "OK" Button zu klicken.
Hubert sprach von einer "simplen" Möglichkeit z.b. durch anlegen einer Datei die etwas "signalisiert".
die Datei "könnte" (Text) Informationen enthalten um Befehle auszuführen um z.b. aus dem Clipboard was zu entnehmen.
HaPe sprach nun davon wie man es "richtig" machen müsste mit 2 Windows Apps ... die sollten direkt "kommunizieren"
das erfordert jedoch Windows API Kenntnisse welche über den Stand eines "einfachen" Xbase++ User hinausgeht.
mein Vorschlag liegt dazwischen und hätte den Vorteil das man keinen Thread zu "lauschen" benötigt.
wenn ich auf einen Button klicke "suche" ich die andere App, dann das Control auf der Form ( ähnlich DrawingArea:Childlist() ) und dann die Aktion z.b. "füllen" eines "WC_EDIT" (SLE) Control. bei einem Bitmap könnte man über das Clipboard gehen und in der anderen App "Strg-V" simulieren.
klar das so ein "Benehmen" gefährlich werden "kann" ... aber solange es ohne (sichtbaren) Probleme funktioniert ...
--- snap ---
Du und Deine Gänsefüßchen...
Nochmal: Man tut das nicht. Wenn Du mühselig ein Eingabefeld gebastelt hast, z.B. das eine Uhrzeit mit Doppelpunkten erwartet und auch dafür sorgt, dass keine Buchstaben vom User eingegeben werden können, und da kommt so ein Schurkenprogramm und ballert Dir "ABCDEFG" rein, freust Du Dich dann?
Das wäre für mich Grund genug, mal schnell ein WM_QUIT in die andere Richtung zu schicken. (Über die Thread Message Queue des Absenders natürlich. Würde bei Xbase übrigens nicht funktionieren, da braucht es drastischere Massnahmen.)
Eine etwas sauberere Möglichkeit, die nebenbei noch das Ausfüllen von Nicht-Edit-Controls (z.B. Eingabefelder im Browser) möglich macht, geht so:
Hotkey mit dem Betriebssystem registrieren und dann den Anwender diesen Hotkey im Zieldatenfeld drücken lassen. Auf dieses Kommando hin dann über die Hardware Event Queue Buchstabe für Buchstabe auf die Reise schicken. Geht echt cool. Oder die Daten (z.B. ein Array) ins Clipboard stellen und dann Strg-V schicken. Wenn die Applikation auf der anderen Seite (und das kann z.B. auch über einen Browser gehen) dann solche Daten erwartet, sind die -zack- drüben. Ich befülle so z.B. SAP-Masken, die über siebzehn Ecken und am Ende einen Browser auf dem PC zu bearbeiten sind.
Viele Grüße
Michael