hallo!

hab zwar hier meine erste Anfrage gestern gepostet, aber nachdem ich mirs nochmals durch den kopf gehen hab lassen, würde ich folgendes vereinfacht sagen:

im tmemo soll das caret an die letzte position der letzten zeile gesetzt werden und diese soll im fenster noch sichtbar dargestellt werden ("command nachbilden"), soll heißen ein scrollen ist notwendig, wenn der inhalt nicht ins fenster passt.

wie mach ich das realisieren, wenn die application schon in einem (indi) thread läuft, ohne dass sich dieser mit den windowsmessages fürs caret setzen schlägt? könnte da bitte jemand einen source code posten, der es schon gemacht hat oder weiß wie es geht?

hab das als newbe leider noch nie gemacht und würde da bitte hilfe brauchen.

danke schon jetzt für jeden tipp.

stephan.

Hallo Stephan,

probiere es so:

markieren

Delphi-Quellcode:

procedure TDemoForm.ButtonClick(Sender: TObject);
begin
  Memo.SelStart := Length(Memo.Text);
  Memo.Perform(EM_SCROLLCARET, 0, 0);
  Memo.SetFocus;
end;

Grüße vom marabu

und wie kann ich dabei verhindern, dass ich von der letzten position woandershin navigieren kann?
ich will nämlich den caret an der position fixieren. sorry, hab ich vorher zu erwähnen vergessen.

d.h. wenn ich folgendes habe

blablabla
blablabla
meins > x

dann soll ich zwar dort wo x steht was eingeben können, aber ich soll den caret nicht mit der maus oder der tastatur woanders hinziehen können und dort die eingabe machen. ich weiß, dadurch wirds komplizierter, aber im command kann mans ja auch nicht (abgesehen davon, dass bei vielen dann die letzten eingaben kommen).

hast du für das fixieren auf der position da unten auch eine lösung, also dass ich z.b. nicht folgendes bekommen kann.

blablabla
blablahahaXblabla
meins >

zweite zeile ist massgeblich, das soll nicht passieren, dass ich den caret da raufziehe und dort meine eingabe drinnen habe.
außerdem steht der caret in der lösung leider direkt unter der letzten zeile (die ist der promt, dort wo geschrieben werden soll!).

mist, wenn ich das fenster wieder schließe, dann schlägt sich der code wieder mit meinem indi thread und das programm und das fenster hängen sich beiom schließen auf.

Hallo Stephan,

ich habe gerade mal deinen anderen Thread gelesen. Wenn du ein Memo als Konsolfenster missbrauchen willst, dann solltest du keine direkten Eingaben zulassen. Ich würde die Eingaben über die Key-Ereignisse abfangen und dort bewerten um welche Art von Eingabe es sich handelt. Das Memo wird dann zu einem Ausgabefenster. Noch einfacher wäre es, wenn du Befehle in einem gesonderten Edit-Control akzeptieren würdest.

Freundliche Grüße

welchen fenstertyp würdest du stattdessen verwenden statt Tmemo?
es spricht nichts dagegen, dass man die ausgabe umbaut und kein tmemo mehr verwendet, wenn es mit einem anderen "Fenstertyp" auch geht.

wäre richedit eine lösung? und was wäre dann der unterschied zwischen den beiden?

TRichEdit bietet dir gegenüber TMemo die Möglichkeit mehrfarbigen Text auszugeben. Vielleicht solltest du mal nach einer Komponente Ausschau halten, die ein Terminal emuliert. Das sollte deinen Anforderungen am nächsten kommen.

Schau mal hier: klick

danke für den tipp.
ist die positionierung des cursors oder eben auch die "fixierung" mit einem TEdit oder TRichEdit einfacher als mit einem TMemo. und wie läuft das intern ab, verursacht das setzen des cursors dort auch laufend windowsmessages?

denn wie gesagt, ich suche nach einer lösung, die mit indi-threads problemlos arbeitet und zu keinem deadlock führt.
achja, und ich habe leider nicht viel zeit, dass ich viele varianten ausprobieren kann. deshalb auch mein erster weg hier ins forum, um das problem auf diese art parallel zu meinen versuchen zu lösen.

Fast alles in deinem Programm läuft über Windows Nachrichten, sobald du eine Benutzeroberfläche bereit stellst, aber das dürfte eigentlich kein Problem darstellen - der Zugriff aus einem selbstgeschriebenen Thread auf Komponenten im VCL Main Thread ist ja in der OH beschrieben.

Wer konsumiert eigentlich deine Konsoleingaben und wer produziert die Ausgaben? Ist das ein Prozess, denn du selbst geschrieben hast? Kannst du nicht ein wenig mehr zu deinen Anforderungen schreiben? Was sind das für Indy-Threads? Mir fehlt momentan die Bodenhaftung und so kann ich dir schlecht helfen.

das ganze sieht so aus:
server (mein tool) kommuniziert via tcp mit client. client erhällt daten von beliebiger anwendung, die damit arbeiten will oder soll.

server sucht nach verfügbaren geräten, mit denen es kommunizieren kann. kommunikation erfolgt durch tastendruck, d.h. eine taste löst eine aktion aus, sagen wir z.b. r löst einen reset auf standardeinstellungen aus usw.

jetzt muss es aber möglich sein, dass das tool/server, der im hintergrund läuft, gleichzeitig mehrere anwendungen bedient, also mehrere fenster gleichzeitig offen hat. also merken, was wohin gehört, damit die daten ins richtige fenster kommen. und jede dieser instanzen läuft damit in einem eigenen thread (also die kommunikation zwischen server und client). und für die tcp verbindung ist indi verantwortlich.

beispiel:
anwendung a ruft das tool/server auf und sucht nach gerät x um mit diesem zu kommunizieren.
anwendung b ruft das tool/server auf und sucht nach gerät y um mit diesem zu kommunizieren.
anwendung c ruft das toll/server auf und sucht nach gerät z um mit diesem zu kommunizieren.

also parallelität ist hier notwendig.

jetzt klarer? und nun soll die verbindung zu gerät z beendet werden und sagen wir, wir wollen auf gerät u zugreifen, dann hängt sich mein terminal genau dort auf, wo ich den cursor im tmemo setze. die pfeiltasten werden nämlich nicht vom keypress erkannt (warum ist mir zwar nicht ganz klar) und daher könntest du herumnavigieren im fenster. folglich setze ich den caret permanent retour auf die richtige position. d.h. du siehst nur ein kurzes flackern und der caret steht wieder, wo er vorher war. nur durch das permanente setzen des caret (weil eben die pfeiltatsten nicht abgefangen werden) crashed da etwas beim terminieren der threads. achja, was das tool respektive terminal auch noch macht ist permanent (d.h. in sinnvollen abständen) zu schauen, ob die gegenseite überhaupt noch da ist (also ein keepalive bzw. isalive).

alles klar?

Was spricht gegen ein Consolen-Programm?