KeyPress unter Form2 funktioniert nicht.

[akurka]

Hallo Frank
Habe beim Form2.Image2.Canvas.. überall auf Form2.Image2.Picture.Bitmap.Canvas... geändert.
Nun das Bild flackert nur jetzt .
Muss ich noch mit Flags sichern das es nur einmal durchläuft?
Gruss Anton

[akurka]

Hallo mitenand
Jetzt lauft richtig.

Es hat nur einmal die Zeile mit
"Application.ProcessMessages" am richtigen Ort gebraucht.

Vielen Dank an Alle.
Gruss Anton.

[akurka]

Hallo mitenand
Jetzt lauft richtig.

Es hat nur einmal die Zeile mit
"Application.ProcessMessages" am richtigen Ort gebraucht.

Es darf wirklich nur einmal pro Formular eingefügt werden, sonst
verschwindet das Menue.

Vielen Dank an Alle.
Gruss Anton.

[Mavarik]

Zitat von akurka:

Es hat nur einmal die Zeile mit
"Application.ProcessMessages" am richtigen Ort gebraucht.

Es darf wirklich nur einmal pro Formular eingefügt werden, sonst
verschwindet das Menue.

emmm NEIN... Application.ProcessMessages kannst Du fast ohne Ausnahme so oft wie Du willst einfügen.
Das darf nix ändern.
Ich Denke Du hast ein Design Problem, wie Du die Sachen Ausführst...

Jede Procedure die Du ausführst muss nach wenigen ms beendet sein, sonst bekommst Du das bekannt [Programm reagiert nicht mehr].
Wenn Du also eine Routine hast, die auf etwas (oder ein Ereignis) wartet, musst Du Application.ProcessMessages innerhalb der Schleife verwenden.

Alternativ kannst Du für zyklische Dinge auch einen Timer verwenden.

In der Regel ist aber für diese Dinge ein Thread angesagt. (VCL Aufrufe dann natürlich mit Syncronize)

Mavarik

[himitsu]

Nein, bei ProgressMessages muß man dennoch aufpassen, denn es führt Messages (z.B. Timer oder irgendwelche Maus-/Tastenevents) sofort aus und der eigentliche Code wartet so lange, bis er alles Anstehende abgearbeitet wurde.
Und man kann das ProgressMessages bis ins unendliche verschachteln, wenn in einer der ausgeführten Events Dieses nochmal vorkommt ... dann kann es passieren, daß der ursprüngliche Code, nach dem ersten ProgressMessages, lange/ewig wartet, bis hoffentlich irgendwann mal alle Events verarbeitet wurden.

[Sir Rufo]

Aus dem Grund sollte man sich überall wo man Application.ProcessMessages verwendet auch noch ein { TODO : Should be done better } hinschreiben.

Als Workaround gesehen ist das erst mal ok, sollte aber beizeiten anders gelöst werden (Thread oder Event-gesteuert).

[Mavarik]

Zitat von Sir Rufo:

(Thread oder Event-gesteuert).

Logisch...

Es sei den, die Aktion/das Fenster soll/muss Modal sein.

[himitsu]

Das Schönste Problem, was mir öfters passiert ist, in Verbindung mit den Messages:
Beim Schließen einer Form soll eventuell eine Meldung angezeigt werden.

Also wurde nach/beim Schließen ein ShowMessage eingeblendet.
ShowMessage hängt sich aber an die ActiveForm und wenn die "Active" noch die gerade Schließende ist, dann beendet diese Form den Dialog,
sobald sie entgültig weg ist, womit der Dialog garnicht, bzw. nur für wenige Millisekunden sichtbar ist.

Oder im ProgressMessage werden Dinge schon gemacht, die eigentlich erst nach Ende der Funktion passieren sollen ... so kann man sich tolle Mehrfachufrufe erzeugen, oder etwas löscht sich selber unterm Arsch weg.

[Sir Rufo]

Nachdem ich mir den Quellcode einmal angesehen habe, beschleicht mich der Verdacht, dass hier ein altes Konsolen-Programm 1:1 in eine GUI-Anwendung umgewandelt werden soll.

Dieser Screenshot bestärkt mich weiter in meinem Verdacht
OPTI-09_5.jpg

Mit ein paar simplen Application.ProcessMessages ist es da aber leider nicht getan.

Auch ist die RSCOM-Unit nicht wirklich dafür ausgelegt und sollte nur mit Vorsicht genossen werden oder entsprechend umgebaut werden.

Wenn wir mal den hierfür in Frage kommenden grundlegenden konzeptionellen Ansatz betrachten, so haben wir:

1. die Kommunikation mit der CNC-Maschine (Daten-Sammler)
2. die Anzeige der gesammelten Daten

Hierbei sollte A in einem eigenständigen Thread laufen und B einfach nur die Daten anzeigen und bei einer Änderung refreshen.

[Mavarik]

Zitat von himitsu:

Nein, bei ProgressMessages muß man dennoch aufpassen,...

Zitat von Mavarik:

fast ohne Ausnahme
Mavarik