Tastatur Eingabe im Canvas Objekt

[akurka]

Hallo bcvs
Warum schlägst Du im Mainform doch die TForm?
Was hätte ich für Nachteile wenn ich das ganze als Konsolen programm
umschreibe ?
Mit wingraph kann ich doch auch graphiken machen.
Und die alte Programmstruktur kann ich praktisch unverändert übernehmen.
Jetzt sage ich etwas ketzerisches :
dem Benützer ist es egal ob das Programm im OOP oder Konsole geschrieben ist, hauptsächlich es läuft fehlerfrei.

Ich verstehe, wenn man etwas völlig neues schreibt, dass man es OOP
machen muss.
Aber in meinem Fall komme ich langsam zu der Ueberzeugung dass ich mir nur eine menge Probleme einhandle.

Was sind also die hauptsächliche Probleme in einem Konsolenprogramm
der auch Graphiken benützt ???

Die Frage geht auch an p80286

Gruss Anton

[p80286]

Natürlich kannst Du das machen, man kann auch mit einem LKW Brötchen holen gehen. Will sagen, ein Windowsprogramm tickt anders als ein Konsolenprogramm. Solange Du Dich darauf beschränkst eine Datei einzulesen und diese zu verarbeiten, bist Du mit einem Konsolenprogramm gut bedient. Kommt der Benutzer mit ins Spiel, mag man gerne darüber diskutieren, was besser ist, solange das Schema Benutzeraktion-Programmaktion-Benutzeraktion...... eingehalten wird. Wenn wie in Deinem Fall(?) parallel zur Benutzerinteraktion auch Daten eingelesen werden sollen, dann ist das Windowsprogramm ganz klar im Vorteil, weil es von vorneherein darauf ausgelegt ist. Ein weiterer Vorteil des Windowsprogramms ist die Skalierbarkeit der Oberfläche, die das Konsolenprogramm nicht bieten kann, da bist Du auf 80x25 Zeichen festgelegt (oder wieviele Zeilen kann der Dos-Prompt?).
Ich kann Dir nur nochmal ans Herz legen, zu überlegen was Dein Programm leisten soll, incl. der Benutzerschnittstelle, und dann solltest Du Dich entscheiden wie Du es umsetzen willst.

Ich kann Deine Bedenken nachvollziehen, mir ging's ähnlich, trotzdem kann ich nur sagen, es lohnt sich.

Gruß
K-H

[akurka]

Hallo p80286
Scheinbar sprichts Du aus Erfahrung.
Für mich ist es aber schwierig zu beurteilen welche Lösung besser ist. Da muss ich mich auf Dein Urteil verlassen.

Darf ich kurz skizziren was der alte Programm OptiNumeric(PC Programm unter win98) macht.

1.)
Die CNC sendet Meldungen an PC (rs232) über Istwerte,Sollwerte,Zustand der Eingänge und welche CNC-Satz gerade abgearbeitet wird. Die CNC kann auch völlig unbhängig vom PC laufen, wenn die rs232 abgekoppelt ist, läuft die CNC weiter mit gespeichertem CNC Programm.
2.)
Der Benützer kann neue Programme erstellen, jeder neu eingegebene CNC Satz wird sofort an die CNC weiter gesendet.Das gleiche gilt auch für
andere Eingabe wie Maschinenparameter, Regelkreisparameter usw.
3.)
Die Daten aus den empfangenen Meldungen werden angezeigt. Einerseits
als text oder als Graphik (gefahrene Strecke).
Die einzelne Menüs sind völlig unabhängig. Die Menuewahl wird an der CNC durch Betriebswahlschalter vorgenommen
(MeldungsByte Status.CNC.ZBETR).Es gibt keine Interaktion zwischen den Menüs.
---
Also das PC programm ist im prinzip ganz dumm.

Der Empfang der Meldungen im alten Programm ist durch Polling bewerkstelligt. Das Programm lauft immer in FullScreen, schon darum
weil z.Bsp die Istwerte sollen mit Abstand auch noch lesbar sein.
---
Mein Ziel ist genau die gleiche Funktionalität mit ins WinXP/win7 zu
portieren. Ich habe versucht das alte Programm mittels DOSBox laufen
lassen, das Ganze ist wegen der RS232 sehr unzuverlässig.
Darum habe ich die ganze Kommunikation versuchsweise in einen Thread
verlagert (vorläufig ohne Synchronisation). Und ziemmlich ausgiebig
mit Erfolg bis 230,4 kBaud getestet. Falls die Kommunikation nämlich durch Windows verzögert wird(was ja beim WinXP passiert) koppelt sich der CNC sofort ab (polling unter WinXP geht nicht).

Was meinst Du dazu ?

Ich möchte Dir noch eine PN senden.
Gruss Anton

[akurka]

Hallo bcvs
Gemäss Deinem Vorschlag habe ich den Programmteil (NCAS00)nctbas01 als methode von TForm2 sowie alle anderen zugehörige proceduren.
Und alle Bildzugriffe im Form2 auf Paintbox ergänzt.
Der wechsel von Form1 zu Form2 habe ich wie folgt gelöst:

Delphi-Quellcode:

case Status.CNC.ZBETR of
                    0..8,
                    10..14: begin
                              Form2.Show;
                              NCAS00.Form2.nctbas01;{ Modul 'NCTBAS00' }
                            end;

Die Istwert-Anzeigen im Menü REF/MAN funktionieren, aber das Edit feld
bleibt ohne fokus, somit ist keine Eingabe möglich.
OnkeyPress habe ich sowohl in Form1 wie auch in Form2.
was mache ich falsch ?

Uebrigens bin ich paralell dazu daran, dass Gleiche auch als Consoleprogramm zu machen, so kann ich es vergleichen.
Gruss Anton

[bcvs]

Hallo Anton,

läuft das case Status.CNC.ZBETR of immer noch in der Schleife repeat until not(ord(Status.CNC.ZBETR) in [0..8,10..15]); ?

Wenn ja, wird da auch irgendwo Application.ProcessMessages aufgerufen?

Zitat:

das Edit feld bleibt ohne fokus, somit ist keine Eingabe möglich.

Ist denn das Programm generell noch bedienbar, d.H. kannst du Form2 mit dem X schließen?

[akurka]

Hallo bcvs
Ja, das war es !! Vielen Dank für den Tipp.
Ich habe die Application.ProcessMessages in der innerste Schleife von
procedure TForm.MAN eingefügt. und jetzt funktioniert die Eingabe.
Die erste Schleife ist in TForm1(CNC.ZBETR), die zweite im TForm2.nctbas01 und die dritte im Tform2.MAN.
Ich verstehe die Wirkung noch nicht ganz.
Muss man die Application.ProcessMessages immer in eine Schleife einfügen ?
Wenn ich aber die repeat Schleife weglasse, lauft es aber nur einmal
durch ?
Oder verstehe ich es falsch?

Nochmals vielen Dank.
Gruss Anton

[bcvs]

Zitat:

Ich verstehe die Wirkung noch nicht ganz.
Muss man die Application.ProcessMessages immer in eine Schleife einfügen ?

Ich versuchs mal zu erklären:

Windows ist ein Nachrichtenbasiertes System. Ein Windows-Programm wird von der Message-Loop gesteuert. In Delphi bekommt man die nicht zu Gesicht. Die verbirgt sich hinter dem Aufruf Application.Run in der .dpr- Datei deines Projektes.

Grob gesagt schickt jede Aktion wie z.B. ein Button-Klick eine Message an Windows, die dann in der Message-Loop verarbeitet wird. Die ruft dann die entsprechende Behandlungsroutine auf und sorgt damit dafür dass dein Programm weiterläuft und Windows bedienbar bleibt. Ein Windows-Programm läuft deshalb nicht in einem Stück durch wie ein DOS-Programm, sondern es wird, durch die Messages gesteuert, mal hier und mal da ein Programmteil ausgeführt. Die Reihenfolge richtet sich nach dem Eingang der Messages in der Message-Loop.

Wenn jetzt eine Schleife so gebaut wird, dass keine Messages abgearbeitet werden können, weil die Programmkontrolle nicht an Windows zurückgegeben wird, kann die Messageloop keine Messages abarbeiten und das Programm hängt.

Deshalb muss in einer Schleife, in der irgendwelche Aktionen stattfinden, die die Oberfläche betreffen dafür gesorgt werden, dass die anstehenden Messages abgearbeitet werden können. Das macht das Application.ProcessMessages. Ohne sieht es in deinem konkreten Fall so aus: Du rufst innerhalb der repeat-Schleife Form2.Show auf. Das wird auch noch ausgeführt. Jetzt schickt das Form2 eine Message an Windows mit dem Inhalt "Setze Focus auf Edit1". Diese Message kann aber nicht abgearbeitet werden, weil dein Programmfluss noch in der Repeat-Schleife festhängt.

Allerdings muss man aufpassen: zuviel Application.ProcessMessages kann auch schädlich sein. Das führt aber jetzt zu weit.

Ich hoffe, ich konnte das einigermaßen erklären. Wenn ich noch was vergessen habe, korrigiere man mich.