![]() |
Andere Programme ansprechen
Folgender Gedanke:
Ich würde gern bei jedem Textfeld jedes Programmes eine Dropdownliste realisieren. wer nicht genau weiß von was ich spreche, es gibt beim IE ein Tool das genau diese funktion besitzt Sprich, wenn ich in ein textfeld etwas eingebe wird der Inhalt gespeichert und beim nächsten mal eingeben des selben textes ist dieser in der dropdownliste auswählbar. nur bräucht ich das eben für jedes programm das läuft. Für gedankengänge bin ich ebenfalls dankbar. |
Hallo und herzlich Willkommen im FOrum!
Mal so zum verständniss, Du möchstest laufende Programme in einer ComboBox anzeigen und auswählen können!? Grüsse, Daniel :hi: |
Also, wenn ich das richtig verstanden hab, dann willst du, dass bei jedem Fenster deines Programmes in jeder Combobox die gleiche Auswahl an Adressen besteht. (soweit richtig?) Dazu müsstest du einfach nach jedem Drücken der Entertaste in der Combobox den gerade eingegebenen Text in eine Ini-Datei (oder ähnliches) speichern. Dann kannst du mit ReadSections / ReadSectionValues die Einträge aus der Ini direkt in die Combobox auslesen. Hast du sowas in der Richtung gemeint (oder bin ich mal wieder total falsch? :mrgreen:)
Man liest sich, Stanlay |
Oh....jetz glaub ich hab ich das verstanden....ich glaub, ich war doch total neben der Reihe! Du willst, dass du, wenn du in irgendein beliebgiges textfeld in irgendeinem beliebigen programm was eingibst, der Inhalt dieses textfeldes im zugehörigen Programm später wieder mit einer Combobox auswählbar ist, oder? Falls du das gemeint hast, könnte ich mir vorstellen, is das n Haufen Arbeit bis unmöglich...
(oder hab ich schon wieder danebengetippt?) |
Du möchtest also, wenn du z.B. Start -> Ausführen "Regedit" eingibst und beim "calc" eingibst, dann möchtest du beim übernächsten mal wieder "Regedit" eingeben, aber es reicht schon wenn du "R" eingibst, denn dann erscheint in der Liste schon "Regedit".
Dass meinst du doch, oder? Windows schreibt dies alles in die Registry, aber du kannst es auch in eine Textdatei schreiben. Weis zwar nicht wie, aber kannst ja mal probieren. :) |
Hallo,
das wäre dann wohl eine Autovervollständigung. Aber das über die Registry laufen zu lassen muss nicht umbedingt sein. Lieber File. Grüsse, Daniel :hi: |
Moin Tiramisu,
interessante Idee. Ich hätte da zwar eine grobe Vorstellung wie man das tricksen könnte (ob's so geht weiss ich noch nicht), allerdings müsste Dein Programm dafür ständig laufen, und es müsste alle diese Daten selber verwalten, wozu dann natürlich auch eine eindeutige Identifikation des entsprechenden Feldes gehören würde. Dazu müsstest Du dann entweder ständig alle Fenster durchgehen, oder das starten von Programmen abfangen, um sie in eine Verwaltungsliste mit aufzunehmen. Mit den Einzelheiten hab' ich mich jetzt noch nicht befasst, aber es erscheint mir doch recht aufwändig zu sein. |
Ja denk ich auch das das etwas aufwendig sein würd
Ja aber generell, ich habe das gemeint mit der Autovervollständigung. Aber kann man nicht den focus eines Textfeldes eines anderen Programms erfragen ??? |
Moin Tiramisu,
den Inhalt eines Edits auszulesen dürfte meist kein Problem sein. Die Messages WM_GETTEXT oder EM_GETSELTEXT wären dafür geeignet. Beispiele, zumindest für WM_GETTEXT, solltest Du hier ein paar finden können. |
Geht sowas denn? Ich meine, dazu müsste man doch jedes Fenster praltisch "registieren", um es nachher auch wiederzufinden, oder. Und dann müsste man wiederrum alle Textfelder in dem betreffenden Fenster registrieren. Wie macht man denn sowas? (ich glaub, das gibt am ende so richtig schön viel daten :mrgreen:)
|
Moin Stanlay,
da hast Du wohl recht, da kommt, zumindest im Laufe der Zeit, eine Menge Daten zusammen. Das Hauptproblem seh' ich im Moment darin zu erkennen, ob ein Control ein Editfeld ist. |
Zitat:
Zitat:
Ich sehe das Problem wo ganz anders. Eine Combobox reagiert auf ganz andere Nachrichten, wie ein Edit. Du müßtest also auch die Fensterprozedur umbiegen. Aber da beleibt immer noch das Problem, wie du der fremden Anwendung klar machen willst, dass es jetzt CB_GETCUSEL zum Auslesen nehmen muß anstatt WM_GETTEXT? :shock: Fensterstile kann man ja mit SetWindowLong ändern, aber in Fremden Prozessen wird auch das schwierig, Aber du willst ja gleich die ganze Fensterklasse austauschen. Um mal ein Beispiel heranzuziehen: Du willst in einen Käfer die Scheibenwischer eines Mercedes einbauen. Selbst wenn du das schaffst, mußt du ja noch die Drähte irgendwo anschließen. Und die sind entweder zu kurz oder der Motor liefert die falsche Spannung oder sie sind anders gepolt oder oder oder ... Hinzukommt, dass du die Scheibenwischer auch noch mit dem Hebel im Mercedes bedienen willst und sie noch auf dem Hebel im Käfer reagieren sollen. Also ich sehe da irgendwie schwarz. :roll: Also ich würde an deiner Stelle lieber zum nächsten Italiener um die Ecke gehen und eine Tasse Tiramisu :wink: schlürfen und mir ein neues Projekt ausdenken. |
Moin Luckie,
GetClassName ist mir durchaus bekannt ;-) Aber bist Du mal so gut mir zu verraten, wie Du automatisch aus dem Namen darauf schliessen willst, dass es sich um ein Edit Feld handelt? Der Standardklassenname wäre EDIT, die "normalen" Edits bei Delphi haben den Klassennamen TEdit. Aber theoretisch könnten die auch TGnpf, oder sonstwie heissen. Mein Problem wäre halt, dass mir im Moment nicht klar ist, wie ich, per Programm versteht sich, ein Control eines beliebigen Klassennamens als EDIT identifizieren soll. |
Hm, OK, aber das "Scheibenwischer-Problem" besteht weiterhin. :wink:
|
Zitat:
Aber im Allgemeinen: Dann wäre die Durchführung eines solchen Unternehmens quasi gar nicht bis unvorstellbar schwer zu bewerkstelligen, oder? |
Moin Stanlay,
Zitat:
|
Les dir mein erstest Posting in diesem Thread noch mal durch.
|
:oops: Jaja...wer lesen kann, ein bisschen Gedult hat und nicht immer gleich alles fragt, was er denkt, ist eindeutig im Vorteil. Sorry :oops:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:37 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz