Tastatur Eingabe im Canvas Objekt

[akurka]

Hallo
Wenn mehrere Menüs mit Image Componente/Canvas objekt aufgebaut sind funktionierte in diesen Menüs die Editkomponente nicht mehr.
Gibt es ausser TastaturHook DLL noch eine
andere Möglichkeit für Eingabe über Tastaur oder Maus die in beliebigen Menüs(und damit in verschiedenen Forms) funktionieren würde ?
Ich habe schon verschiedentlich Warnungen gelesen über die TastaturHooks. Ist etwas wahres daran ?

[Luckie]

Menüs mit Eingabefeldern? Menüs sind für mich da zu da, Programmfunktionen aufzurufen oder auszuführen, aber nicht für Eingaben.

[akurka]

Hallo Luckie,
Vielleicht meinen wir nicht das Gleiche mit Menüs.
Bei einem Bediener Menü von einer CNC Steuerung möchte man einerseits Istwerte sowie auch graphische Darstellung des gefahrenen Wegs sehen. Und auf dem gleichem Menü möchte man die graphische Darstellung zwischen der Ebene1 (X,Y) in Ebene 2(Z,W) oder Nr3 usw. Dazu muss man die Ebene Nr. Eingeben. Da will man nicht Menue wechseln sondern nur eine Teil-Graphik aufbauen. Und das ist nicht das einzige. Auch Istwerte von z.Bsp 16 Achsen
müssen mit jeweils zu 8 Achsen (möglichst grosse Ziffern)umgeschaltet werden. usw. usw.

[himitsu]

Das DevExpressMenü kann sowas.
Da kann man Edits, CheckBoxen, ComboBoxen usw. ins (Haupt)Menü einbauen.

[akurka]

Hallo Himitsu

Zitat:

Zitat von himitsu (Beitrag 1277954)

Das DevExpressMenü kann sowas.
Da kann man Edits, CheckBoxen, ComboBoxen usw. ins (Haupt)Menü einbauen.

Danke für den Hinweis, aber 700$ bis evt. 2000$ möchte ich nicht ausgeben.
Ich denke eher an etwas was ich selber machen kann.

Meine Frage ist:
habe ich ausser TastaturHook eine andere Alternative ?
Gruss Anton

[himitsu]

Die Tastatureingaben gehen ja ans Menü und nicht an die Items, also müsstest du das Menü um eine entsprechende Tastaturbehandlung erweitern, welche dann an die Items weitergeleitet werden.
Und wenn ein Item im Memü den Eingabefokus bekommen soll und sich das Menü schließt, wenn es den Fokus verliert, dann wirst du eventuell auch noch ein eigenes Menü basteln müssen.

[akurka]

Ja was meinst Du mit den Items genau ? resp. was meinst du mit Menü ?

Ich habe bereits ein erste Versuch gestartet mit TastaturHook DLL
Wenn ich das ganze im Form2 installiere funktioniert es.Eingaben werden versuchsweise in einem Memo angezeigt.
Sobald ich aber in Form2 den Canvas objekt benütze, funktioniert die Tastatur Eingabe nicht mehr.

Muss ich den Tastaturhook in ein Thread auslagern damit es aus allen Form ansprechbar ist ?

[Medium]

Ich glaube hier gibt es ein Missverständnis bzgl. "Menü": Der normale Delphianer versteht darunter ganz spezifisch die TMainMenu Komponente. In der industriellen Maschinen- und Anlagensteuerung, bzw. dem Thema HMI, bezeichnet ein "Menü" in etwa das, was wir anderen hier i.A. als ein TForm verstehen würden. Ein anwählbares Bild, welchen diverse E/A Elemente und Grafiken beinhaltet, die zur Steuerung dienen.

So wie sich das hier liest, glaube ich fast, dass letzteres vom TE hier gemeint ist. Allerdings weiss ich dann nicht mehr so 100% wo genau das Problem ist. Ab hier wäre etwas Beispielcode und ggf. ein Screenshot wirklich hilfreich.

[akurka]

Hallo Medium
Danke für die Begriffsklärung. Ich bin eben kein normale Delphianer sondern blutige
Anfänger(im pensionsalter).
In dem Fall das, was ich unter Menü verstehe ist die Form.
(Ich komme aus der Steuerungsbranche wie Du richtig festgestellt hast).

Ich glaube Code ist zu umfangreich, aber ich sende ein Screenshot von der TForm2 an der ich momentan arbeite.

Es gibt in diesem Menü(Form2.Canvas..) nur eine einzige Eingabe (Buchstabe A) zum Istwertanzeige toggeln zwischen Achse1 bis 8 oder 9 bis 16. (siehe Anzeigewechsel<A>)
Das ist erste Versuch,beim nächste Menü(Form3: Programmiermenü) wird es viel mehr Eingaben geben.

Das es im Canvasobjekt keine Editkomponente funktioniert, habe ich auch schon festgestellt.
Ich habe es mit TastaturHook DLL probiert aber es funktioniert
auch nicht.
Andereseits sind die Globale Variable die ich mit eine Thread ab
Comport einlese in allen Forms verwendbar.
Darf man also den TastaurHook DLL Zugriff
in den gleichen Thread zufügen ?
Oder was habe ich ausser teuere Komponenten Einkaufen für andere Möglichkeiten ?
Gruss Anton

[bcvs]

Wenn ich das richtig verstehe, sollen da keine langen Texte eingegeben werden, sondern nur ein Zeichen zur Programmsteuerung. Dann könnte man doch einfach im OnKeypress des Forms auf den Tastendruck reagieren.

Evtl. muss KeyPreview auf true gesetzt werden.

[himitsu]

Nicht alle Tasten stehen in OnKeyPress zur Verfügung. (Pfeil-Tasten z.B.)
In diesem Fall OnKeyDown oder OnKeyUp verwenden.

Alternativ kommt man über GetAsyncKey an die Tasten, aber ein Event hat viele Vorteile. (voallem daß sie sofort reagieren und man nicht pollen muß)

[akurka]

Hallo bcvs
Ja richtig, aber es werden in den späteren Menues/Forms u.A auch Koordinateneingaben folgen.
Aber onKeyPress oder Down.. funktionieren unter Canvas nicht,ob ich keyPreview auf on oder off hat kein Einfluss.
Die onkey.. funktionieren im Form2 bis zu dem Punkt wo ich mit Button in Form1
der Menüaufbau im Form2 starte (diese wird mit Form2.Canvas.rectangle , row,column ,usw. gemacht.Ab diesen Punkt ist keine Eingabe über Tastatur möglich.
gruss Anton

[bcvs]

Wenn ich dich richtig verstehe, malst du deine Ausgabe auf den Canvas des Form.

Und wo sollen die Koordinaten dann später eingegeben werden?. Du könntest doch deine Ausgabe auch in eine Paintbox malen, die nicht das ganze Form ausfüllt und z.B. oberhalb noch ein Editfeld oder sonstige sinnvolle Komponenten reinsetzen.

[akurka]

Hallo bcvs
ja, es wird alles auf der FormX.Canvas dargestellt, sowohl die div. Anzeigen sowie die Eingaben. Anzufügen ist,dass ich in der Gestaltung
nur sehr wenig Spielraum habe, die Kunden benützen die bisherige Menüs schon Jahrelang. So soll es in der Aufteilung sowie in der Bedienung gleich bleiben.
Du fragst, wo sollen die Koordinaten eingegeben werden.
Ich lege eine Abbildung von alten Menüs bei. Das wird dann das neue Form3/Progmenue sein. Das Ganze aufzuteilen ist praktisch unmöglich, darum muss ich eine Möglichkeit finden für eine direkte Eingabe auf dem Canvas.
Himitsu's Vorschlag für Form2/MAN-REF Menu mit GetAsyncKeyStatus funktioniert, für ein einziges Zeichen geht es noch. Für lange und viele Eingaben ist es aber sehr umständlich.
Gruss Anton

[pelzig]

Kann zwar nicht so ganz folgen, aber:

Warum nicht ein unsichtbares TEdit aufs Formular klatschen und je nach dem, was der Anwender drückt, sichtbar machen und dann den Focus auf das TEdit setzen?

Eingaben werden dann vom TEdit entgegengenommen und sollten mit der Esc-Taste verworfen werden (wodurch TEdit wieder versteckt wird).

Allerdings müssten dann Eingaben, die ins TEdit getippt werden, noch mit Return bestätigt werden.

MfG


P.S.: Geile Screenshots mit verwaschenen Schriftgrö0en < 4. Weiter so!

[akurka]

We know that focus is the ability to receive user input through the mouse or keyboard. Only the object that has the focus can receive a keyboard event. Some controls, such as TImage, TPaintBox, TPanel and TLabel cannot receive focus. The primary purpose of most graphic controls is to display text or graphics.

aus "Delphi about Technology" page

[bcvs]

Zitat:

darum muss ich eine Möglichkeit finden für eine direkte Eingabe auf dem Canvas.

In einen Canvas kann man nichts eingeben, darauf kann man nur zeichnen. Alternativ zu pelzigs Vorschlag könntest du auch ein TEdit benutzen, dass ständig den Focus hat. Im OnKeyDown des TEdits reagierst du dann auf Sondertasten wie F1 bis F10 oder deine anderen Steuertasten. Wenn die ankommenden Zeichen als Koordinateneingabe interpretiert werden (wie das unterschieden wird, weißt du selbst am besten), werden sie ganz normal ins TEdit eingetippt.

Ich weiß auch immer noch nicht, wie es aussehen soll, wenn längere Werte eingetippt werden. Willst du die einzelnen Zeichen dann gleich auf den Canvas malen?

Wenn das Edit nicht sichtbar ein soll, kann du es auch außerhalb des Forms plazieren , z.B. mit top=-100.

Zitat:

Only the object that has the focus can receive a keyboard event. Some controls, such as TImage, TPaintBox, TPanel and TLabel cannot receive focus.

Deshalb brauchst du ja
1. eine Komponente, in die du zeichnen kannst. Dazu nimmt man normalerweise eine Paintbox.
2. eine Komponente, die den Focus erhalten kann, z.B. ein TEdit.

[akurka]

Halo bcvs
Nun das habe ich schon zweimal probiert und jetzt auch noch drittemal.Die Eingabe ins Edit
hat nach dem (Canvas)Bildaufbau kein Focus mehr, obwohl ich Form2.Edit1.SetFocus auch nach dem
BildAufbau aufgerufen habe. Probiere das mal selber, es geht nicht !

Zitat:

We know that focus is the ability to receive user input through the mouse or keyboard. Only the object that has the focus can receive a keyboard event. Some controls, such as TImage, TPaintBox, TPanel and TLabel cannot receive focus. The primary purpose of most graphic controls is to display text or graphics.
If we want to intercept keyboard input for controls that cannot receive the input focus we'll have to deal with Windows API, hooks, callbacks and messages.

Windows Hooks
Technically, a "hook" function is a callback function that can be inserted in the Windows message system so an application can access the message stream before other processing of the message takes place. Among many types of windows hooks, a keyboard hook is called whenever the application calls the GetMessage() or PeekMessage() function and there is a WM_KEYUP or WM_KEYDOWN keyboard message to process.

To create a keyboard hook that intercepts all keyboard input directed to a given thread, we need to call SetWindowsHookEx API function

Ich habe es mit den Tastatur Hook auch bereits probiert, aber vermutlich nur mit local Hook,
was aber nicht funktionierte, man müsste offenbar Global Hook verwenden.
Gruss Anton

[bcvs]

Das muss aber gehen. Ich vermute, das Problem liegt ganz woanders.

Der Focus hat doch nichts mit dem Canvas tun.
Zeig doch mal ein bischen Code. Wo machst du denn den Bildaufbau? Der gehört ins OnPaint der Paintbox (oder des Forms, wenn du direkt auf das Form malst).

Zitat:

Form2.Edit1.SetFocus

Lass das Form2 weg und schreib einfach

Delphi-Quellcode:

Edit1.SetFocus

. Innerhalb einer Form-Klasse auf die eigene Form-Variable zuzugreifen ist ein schlechter Stil, da nicht sichergestellt ist, dass Form2 immer existiert oder immer so heißt.

[akurka]

Edit1.SetFocus schluckt der compiler nicht.
In der Beilage die zwei relevante units.

[pelzig]

Zitat: „In dem Fall das, was ich unter Menü verstehe ist die
Form.“

Ein Formular/Form ist kein Menü.

Die Objekte auf dem Formular/Form könnten aber Aktionen auslösen, wenn man sie anklickt.

Wenn man die unterschiedlichen Objekte auf dem Formular/Form aber als "Menü" bezeichnet, könnte man "Himmel" auch als "Joghurtbecherboden" missverstehen :wink:

Was meinst Du eigentlich mit "canvas"?

Sorry, kann leider immer noch nicht folgen, worum es eigentlich geht.

"Schweizer Pensionär" gilt nicht als Ausrede für falsche Begriffsbezeichnungen :twisted:

MfG

[bcvs]

Ich denke, du solltest dich erst mal ein bischen mit der Windows-Programmierung und der objektoriententierten Programmierung unter Delphi vertraut machen. Das war wahrscheinlich mal ein DOS-Programm. Das kann man aber nicht einfach 1:1 nach Windows umsetzen.

Unter Windows wird der Programmablauf von Messages gesteuert, auf die man in Delphi in den entsprechenden Ereignissen reagieren kann.

Was mir noch nicht klar ist:

Deine procedure nctbas01; ist eine einfache Procedure, keine Klassenmethode. Von wo wird die überhaupt aufgerufen? Das war in dem Dos-Programm wahrscheinlich die zentrale Ablaufsteuerung. Unter Windows brauchst du das nicht mehr, da Windows die Ablaufsteuerung in Form der Message-Loop schon mitbrint. Bu brauchst nur auf die verschiedenen Ereignisse zu reagieren.

Wo kommt das Status.CNC.ZBETR her?

StatusBild; ist ebenfalls ein einfache Procedure. Das muss eine Klassenmethode sein, die dann im OnPaint aufgerufen werden muss.

Hier mal ein Grundgerüst, wie es laufen könnte:
Mach ein neues Projekt auf und lege ein TEdit und ein TPaintbox auf die Form:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, ExtCtrls;

type
  TForm1 = class(TForm)
    Edit1: TEdit;
    PaintBox1: TPaintBox;
    procedure Edit1KeyDown(Sender: TObject; var Key: Word; Shift: TShiftState);
    procedure PaintBox1Paint(Sender: TObject);
    procedure FormCreate(Sender: TObject);
  private
    { Private-Deklarationen }
    procedure StatusBild;
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin
  Edit1.SetFocus;
end;

procedure TForm1.Edit1KeyDown(Sender: TObject; var Key: Word;
  Shift: TShiftState);
begin
  case key of
  vk_F1 : begin
            // mach wa mit F1
          end;
  vk_F2 : begin
            // mach wa mit F2
          end;
  // hier noch auf weitere Tasten reagieren
  end;
end;

procedure TForm1.PaintBox1Paint(Sender: TObject);
begin
  StatusBild;
end;

procedure TForm1.StatusBild;
{zeichnet das Bildgeruest fuer den 'Man'-Mode und beschriftet es}
begin
  PaintBox1.Canvas.Brush.Color:= clRed;
  PaintBox1.Canvas.RECTANGLE(2,2, BildB, BildH);
  with PaintBox1.Canvas do begin
    Pen.Color:=clBlack;
    Brush.Color:= clYellow;

    // Application.ProcessMessages; // Nein: hier bitte bloß nicht aufrufen !!!!

    // das hier sich wahrscheinlich Routinen, die irgendwo in einer Art Bibliothekt definiert sind
    // Da müssten man noch den Canvas all zusätzlichen Parameter übergeben
    Column(K_X3,255,0);
    Row(K_Y1,0,511);
    Row(K_Y6,0,K_X3);
    Row(K_Y7,0,K_X3);
  end;
end;

[akurka]

Hallo bcvs
Vielen Dank, dass Du Dich so tief mit meinem Projekt beschaftigst.
Ja Du hast recht, aber ich will das ganze riesen Projekt (6 Mannjahre) nicht über den Haufen rühren. Es ist mir schon klar, dass es ein riesen Gebastel ist. Mein Problem ist wie ich das Ganze mit möglichst wenig Aufwand ins Windows übertrage.
Und ich weiss es, dass ich da ein halbes Verbrechen gegenüber Delphi begehe.
Da habe ich mir auch schon überlegt ob ich besser das Ganze als ein Konsolen Programm schreiben soll mit win.crt und wingraph.pas. Was meinst Du dazu ?:?:

Nun zu Deinen Fragen : Die CNC sendet Meldungen(verschieden Lang) über rs232 ,ein thread empfängt die und schreibt die Daten in Glob.Var. Das funktioniert auch recht gut.
Wenn ZBETR=06 (glob.var)wird aus dem Hauptprogramm (Form1) das nctbas01 gestartet - > Form2 -> MAN (Menü MAN/REF).
Hauptprogramm befindet sich in NCPSA0.PAS.
Es ist natürlich jetzt noch vieles auskomentiert und zum Teil als mehr oder weniger Versuchs Programm. Aber mir graut es, dass ganze vom Grund auf neu aufzustellen.
Ich versuche die relevante Teile des Programms zusammenstellen (es ist in etwa ein Zehntel des gesamten)und sende es im Anhang.
Gruss Anton

[bcvs]

OK, da ist auch noch ein Thread involviert. Das macht das Ganze auch nicht gerade einfacher.

Das scheint mir alles ziemlich ineinander verflochten zu sein. Ich denke, du hast zwei Möglichkeiten:

1. Du machst die die Mühe und zerpflückste es und schreibt es windowskonform neu. Dazu gehört dann auch dass man Ausgaben nicht einfach mit Canvas.TextOut auf den Canvas malt, sonder dass alle Canvas-Operationen ausschließlich im OnPaint stattfinden. Ansonsten ist die Ausgabe wieder weg, wenn sich das Fenster neu zeichnen muss, weil z.B. ein anderes Fenster drübergeschoben wurde. Und Grafikausgaben aus einem Thread heraus müssen uber Synchronize erfolgen.

oder:
2. Du machst das mit dem Konsolenprogramm.

Der Mittelweg, den du momentan angefangen hast, funktioniert nicht.

Und wie schon gesagt: lass hier:

Delphi-Quellcode:

procedure TForm1.grafikinit;
begin
  Form1.Image1.Left := 0;
  Form1.Image1.Top := 0;

in den Aufrufen das Form1 weg:

Delphi-Quellcode:

procedure TForm1.grafikinit;
begin
  Image1.Left := 0;
  Image1.Top := 0;

[akurka]

Hallo bcvs
Und wenn ich das main case/sub case als Konsolen programm mache und erst bei der einzelnen Menüs (es sind im ganzen 13 Menüs + 5 Untermenü) als FormX.Paintbox definiere ?

[p80286]

Zitat:

Zitat von akurka (Beitrag 1278185)

Hallo bcvs
Und wenn ich das main case/sub case als Konsolen programm mache und erst bei der einzelnen Menüs (es sind im ganzen 13 Menüs + 5 Untermenü) als FormX.Paintbox definiere ?

Ich denke, Du solltest das ganze Programm neu aufsetzen!
Nein ganz so schlimm ist es nicht, aber als ich eben die Screenshots gesehen habe, hatte ich schon ein Dejavu. DOS-Programme funktionieren anders als Windowsprogramme. Was damals mit

Delphi-Quellcode:

repeat
..
until keypressed

gemacht wurde, ist heute mit

Delphi-Quellcode:

Application.Run

erledigt.
Du solltest dir zuerst einen PAP erstellen, vllt. gibt's den ja auch noch, und dann das als Windowsprogramm neu aufsetzen. (Beinahe)alles was Du damals für die Datenverarbeitung genutzt hast, ist heute auch noch verwertbar, aber auch hier kann ich nur zur Vorsicht raten, denn nicht nur der String hat sich geändert.

Was Deine "Alt-Oberfläche" angeht, die kann man meiner Meinung nach auch mit TLabel und TMemo nachbauen, U.U wäre da auch noch für TFrame ein effizenter Einsatz möglich.

Gruß
K-H

[bcvs]

Genau,

und auf den Thread kannst meiner Meinung mach auch verzichten, wenn Du den CNC-Datenempfang in eine Methode deines Mainforms auslagerst, z.B. so: (zumindest vorerst, bis alles läuft)

Delphi-Quellcode:

type 
  TForm1 = class(TForm)
  ...
  private
    procedure PerformCNCData;
  ...
  end;

procedure TForm1.FormShow(Sender: TObject);
begin
  PerformCNCData;
end;

procedure TForm1.PerformCNCData;
begin
  while true do begin
    byt := READBYTE;
    case (byt and $0F) of
    ...
    end;
    Application.ProcessMessages; // Hier sehr wichtig, damit das Programm noch bedienbar bleibt
  end;
end;

[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

Delphi-Quellcode:

case Status.CNC.ZBETR of

immer noch in der Schleife

Delphi-Quellcode:

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.

[akurka]

hallo bcvs
Also wenn ich Dich richtig verstanden habe, man darf im Programm Schleifen machen.

In meinem Fall ist es so, dass die Tform1 lediglich der Initialisierung der Schnittstelle und starten vom ComPort Thread dient.
Nach dem das CNC.ZBETR empfangen wurde(kommt vom Thread) komme ich in die zweite Schleife in Form2.nctbas01. Hier wird je nach CNC.ZBETR weiter verzweigt in die eigentliche Menüs.
Das ist im vorligende Fall das TForm2.MAN(CNC.ZBETR=6, später kommen andere).
In den ersten zwei Schleifen is also kein Application.ProcessMessages nötig.

Dagegen in der TForm2.MAN musste man es aufrufen.
Diese Schleife wird verlassen, wenn sich CNC.ZBETR ändert, was ja richtig ist.

Und das gleiche Prinzip muss man auch bei anderen Menüs anwenden.
Ich denke jetzt bin ich um einiges optimistischer was das Delphi anbelangt.
Ist es doch besser die Konsollevariante links liegen lassen?

Du verfügst offenbar über recht viel Erfahrung, darf ich Dich auch über
PN ansprechen ?

Gruss Anton

[bcvs]

Hallo Anton

Zitat:

Also wenn ich Dich richtig verstanden habe, man darf im Programm Schleifen machen.

Natürlich darf man das.

Zitat:

In den ersten zwei Schleifen is also kein Application.ProcessMessages nötig

Das kann ich so nicht beurteilen. Wenn die Schleife jedenfalls in einem eigenen Thread läuft, braucht man es evtl. nicht, da der Thread seine eigene Message-Loop hat.

Zitat:

Ist es doch besser die Konsollevariante links liegen lassen?

Ich denke ja.

Zitat:

Du verfügst offenbar über recht viel Erfahrung, darf ich Dich auch über
PN ansprechen ?

Naja, geht so, da gibt es hier mit Sicherheit Kollegen mit mehr Erfahrung. Aber PN trotzdem gerne.

[akurka]

Hallo bcvs

Zitat:

In den ersten zwei Schleifen is also kein Application.ProcessMessages nötig
... Deine Aussage:
Das kann ich so nicht beurteilen. Wenn die Schleife jedenfalls in einem eigenen Thread läuft, braucht man es evtl. nicht, da der Thread seine eigene Message-Loop hat."

Nein die erste zwei Schleifen laufen in keinem Thread.
Ich habe bisher nur den comPort thread, der vom Hauptprogramm Optinum gestartet wurde.
Gruss Anton