KeyPress unter Form2 funktioniert nicht.

[akurka]

Bin schon länger am suchen, kann mir jemand helfen ?

Die Methode Form1KeyPress funktioniert im Form1 problemlos.

Nach dem umschalten auf Form2 (Focus ist aktiv auf Form2) funktioniert die Methode Form2KeyPress nicht.
KeyPreview ist hier auch true.
Das Umschalten von Form1 zu Form2 wird gestartet mit Button1 auf
Form1. Ist das vielleicht ein Problem ?

Das Button1 startet eine neue Unit mit Form2.
Gelbe screen ist in Form2.Image2.
Das angehängte Bild zeigt die beiden Formulare, beim Form2 ist keine Tasteneingabe möglich. Warum ?

[himitsu]

Ist das Form2KeyPress auch dem OnKeyPress der Form2 zugewiesen?


Es gibt zwar ein paar Komponenten, welche die Events/Messages abfangen, bevor sie bei der Form ankommen, aber die sind recht selten.
Vorallem einige ActiveX-Komponenten betrifft das und am Liebsten machen welche von Adobe solch einen Mist. :wall:

[vagtler]

Was heißt "funktioniert nicht"? Ist das Ereignis überhaupt verdrahtet? Kommt eine Fehlermeldung? Passiert gar nichts? Was sagt der Debugger? Wo ist der Quellcode? Wieso muss man sowas den Leuten immer aus der Nase ziehen? Was bedeutet "Das Umschalten von Form1 zu Form2 wird gestartet mit Button1 auf Form1."? Wie wird Form2 erzeugt? Warum werden Komponenten nicht vernünftig benannt?

[sx2008]

Wozu brauchst du das KeyPress-Event überhaupt?
Man kann z.B. auch eine ActionList mit Actions befüllen und jeder Action einen Shortcut (z.B. Funktionstasten) zuweisen.
Im Objektinspektor kann man dann bei Button und Menueitems eine Action eintragen und kann somit die Anwendung per Mausklick und per Tastatur bedienen ohne eine einzige Codezeile dafür geschrieben zu haben.
Man muss nur das OnExecute-Event der Actions befüllen - andernfalls sind die verknüpften Buttons/Menueitems deaktiviert.

http://www.entwickler-ecke.de/topic_...st_1662,0.html

[akurka]

Der Quellcode ist sehr umfangreich, darum wollte ich niemand damit belästigen.
Mit dem Debugger wurde getestet, das Event wurde gar nicht ausgelöst
(breakpoint nicht erreicht im Form2KeyPress).
Ausserdem zeige ich der Zustand vom Zchg = Kopie von key am Display.
Umschalten von Form1 auf Form2 passiert folgendenmassen :
Der Button1 startet zuerst RS232 und damit kommen Meldungen von der CNC ( die sind auch sichtbar
auf dem Monitor (rote Zeichen unten). Wird eine bestimmte Meldung (genau die, welche beginnt mit 04)
empfangen (siehe Fehler Zeile) wird eine Procedur(MAN) in unit NCAS00 aufgerufen.
In der unit NCAS00 ist auch die Form2 deklariert, der ganze Aufbau von REF/MAN Menue wird unter
klasse Form2.Image2 gemacht, alle Anzeigen funktionieren laufend, nur das event für Form2KeyPress kommt beim Tastendruck nicht.
Bevor der Button1 aktiviert wurde, läuft programm in Wartestellung (siehe blaue Bildschirm oben)wo die Grafik in Form1.Image1 aufgebaut wurde. Hier gibt es methode Form1KeyPress die problemlos funktioniert .Form1KeyPress und Form2KeyPress sind praktisch
gleich aufgebaut: Zchg ist globale var typ Char.

procedure TForm2.Form2KeyPress(Sender: TObject; var Key: Char);
begin
Zchg := Key;
end;

resp.

procedure TForm1.Form1KeyPress(Sender: TObject; var Key: Char);
begin
Zchg := Key;
end;

Ich vermute das es etwas zu tun hat mit dem Button1 erreignis.
Wenn das Menue MAN/REF aufgebaut ist, ist der Focus auf die Form2 (das sieht man auf dem Screen).
Da sollte der KeyPress funzen, tut es aber nicht!
Ich verwende nur Standart Delphi7 Komponenten, für die RS232 dann die WinAPI Funktionen.
Ich denke ,dass sollte als Erklärung reichen, falls jemand mehr will gebe ich gern Auskunft.

[Volker Z.]

Hallo,

wenn Du mal das Form2 öffnest und Dir dann im OI die Eigenschaft KeyPreview bzw. das Ereignis OnKeyPress ansiehst, was steht denn da?
Ist dort wirklich: KeyPreview True, OnKeyPress Form2KeyPress? Irgendwie liest sich das, als ob per Copy/Paste Code dupliziert wurde, aber der Event nicht zugewiesen wurden.

Gruß

[akurka]

Hallo
Ja KeyPreview ist im Oi gesetzt. das war das erste was ich gecheckt habe.Irgend etwas stimmt nicht mit dem Focus auf Form2. Das Form2 Fenster ist zwahr aktiv abe lässt sich nicht
mit der Maus bewegen. Form1 Fenster ist inaktiv (oben grau)
und lässt sich ebenfalls nicht mehr bewegen.
Vermutlich verstehe ich das nicht richtig wie das mit dem parent resp child funktioniert.
Bevor der Button1 aktiviert wurde konnte das form1 bewegt werden.
Ich sende Dir die Unit NCAS00 und NCAS30,in der procedur MAN wird das Menue MAN/REF aufgebaut. Da diese Units ursprünglich
von MS-Pascal Modulen stammen, ist dort noch viel auskomentiert.
Gestartet wird MAN durch das der Status.CNC.ZBETR (globale var (record)) wert 8 hat.Diese Record beinhaltet Meldunge
der von der rs232 eingelesen wurde.
Ich bin gespannt was Du dazu meinst.Vielen Dank.
Falls dich interessiert für was das ganze: http://www.antonkurka.ch/KurkaAGSeiten/Kurka_AG.htm
mfg Anton

[himitsu]

Gibt es vieleicht eine Exception, oder ein anderes Fenster, welches sich hinter den Fenstern versteckt und den Fokus wegschnappt? (ShowModal)

Wenn man Screen.OnActiveFormChange und Screen.OnActiveControlChange verwendet, dann kann man irgendwo loggen, wie und wo der Fokus umherwandert,
bzw. mit Screen.ActiveCustomForm und Screen.ActiveControl kann man auch im Debugger die aktuelle Position anzeigen lassen.

Zitat:

Delphi-Quellcode:

procedure TForm2.Form2KeyDown(Sender: TObject; var Key: Word; Shift: TShiftState);
begin
Taste:= Key;
  Refresh;
  Key:= 0;
  Label1.Caption:= IntToStr(Key);
end;

Ich weiß zwar nicht was Taste ist, aber im Label1 wird bestimmt nicht Ordentliches angezeigt.

[akurka]

Hallo Frank
Die Taste ist von Typ Word. Das mit dem TForm2.Form2KeyDown war ein Versuch (der auch nicht mit refresh funktioniert hat), ich möchte lieber aber die TForm2.Form2KeyPress verwenden, weil es key als Char liefert, dies kopiert in Zchg:char kann ich direkt Anzeigen und verwerten.
Die RS232 funktioniert jetzt tadellos, allerdings
mit der RSCOM version (benützt auch direkt WinAPI).
Komischeweise war die davon abgeleitete DLL Version viel langsammer, was auch die Unterbrüche beim Empfang ausgelöst hat.
Dein SimpleComPort konnte ich bis jetzt nicht einsetzen (obwohl es mir besser gefallen hat) weil es beim OPENCOM in Exception ging.
Dagegen habe ich festgestellt bei der RSCOM version das
beim OPENCOM Exceptionen gar nicht abgefangen werden, egentlich
sträflich, aber es funktioniert. Trotzdem wäre ich froh
Deine Version zu verwenden.
Gruss Anton

[Mavarik]

Zitat:

Zitat von akurka (Beitrag 1258538)

Das Form2 Fenster ist zwahr aktiv abe lässt sich nicht
mit der Maus bewegen.

Dann Fehlt ein Application.Processmessages weil sicherlich eine Routine nicht Event-gesteuert auf ein Ergebnis wartet.
Ein Windows Programm reagiert "nur", wenn Du auch in die Application Message-Routine zurückspringst.

Mavarik

[himitsu]

Delphi-Quellcode:

  Key:= 0;  // ich meinte es eigentlich deswegen ;)
  Label1.Caption:= IntToStr(Key);

Gut, das wäre ein Grund, aber wenn die Anwendung hängt, dann sollte sich doch eigentlich Windows melden?

Bei "versteckten" Fenstern:
Im Zweifel einfach mal Alt+Leertaste drücken und schauen ob ein Menü auf geht.
Und im deutschen Windows kann man dann noch mit V das Verschieben aktivieren und via Pfeiltasten schauen ob von irgendwo ein Fenster herkommt.

[akurka]

Hallo Mavarik
ja, tatsächlich es funktioniert,vielen Dank für den Tipp.
Es löscht aber zugleich Hintergund von Image und praktisch alle Werte die nur einmal eingetragen wurden. Wenn ich die Application.Processmessages vor dem Image Aufbau benütze funktioniert wieder dir Eingabe nicht.Siehe Beilage.
Fehlt da noch etwas ?
Gruss Anton

[himitsu]

Wird einfach nur auf das Canvas des Images gezeichnet? (ohne Zwischenspeicherung des Bildes)


@Anhang: Sowas wollte ich schon lange mal machen:
Das FocusDebugger-Datenmodul ins Programm aufnehmen und automatisch erstellen lassen (ansonten nicht vergessen es zu erstellen),
DebugProject und dann das eigene Programm starten ... schon sieht man unabhängig, ob das Programm reagiert und wo der Fokus liegt.

[akurka]

Hallo Frank
die Komponente SaveDialog habe ich auf beiden Formularen aber
offenbar nützt es nicht.Welche Parameter muss man dann setzen zum
zurück speichern ? Es hat eine ganze Menge.
Gruss Anton

[himitsu]

Wenn direkt auf Image1.Canvas gezeichnet wird, dann ist das Ganze wie eine TPaintBox ... sobald etwas das übermals, bzw. ein Neuzeichnen anstößt, dann ist alles weg.

Beim TImage kann man in Image1.Picture.Bitmap.Canvas zeichnen, also wenn in das Image1.Picture ein TBitmap geladen wurde.
Ist beim Zugriff auf Picture.Bitmap kein TBitmap in dem Image1.Picture.Graphic drin, dann wird automatisch Eines erstellt (und ein eventuell anderes vorhandenes Grafikformat wird abei gelöscht).

Muß sich das TImage jetzt neu zeichnen, dann nimmt es dafür das Bild vom Image1.Picture.Grafic (welches ja das TBitmap enthält).

Alles ist immer in Picture.Grafic drin und die anderen Property, wie Icon und Bitmap casten das entsprechend und sorgen vorher dafür, daß dieser TGrafic-Typ auch vorhanden ist.


Der TSaveDialog selber macht nichts, außer über .Execute den Dialog anzuzeigen und über .FileName dann den Namen rauszurücken.
Das eigentliche Speichern muß man dann selber auslösen, über eine der SaveTo...-Methoden des Grafikobjektes.

[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. :-D

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:

Zitat von akurka (Beitrag 1258579)

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...

Delphi-Quellcode:

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

Delphi-Quellcode:

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

Delphi-Quellcode:

Application.ProcessMessages

verwendet auch noch ein

Delphi-Quellcode:

{ 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:

Zitat von himitsu (Beitrag 1258589)

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

Zitat:

Zitat von Mavarik (Beitrag 1258586)

fast ohne Ausnahme
Mavarik

:stupid:

[Mavarik]

Zitat:

Zitat von Sir Rufo (Beitrag 1258592)

(Thread oder Event-gesteuert).

Logisch...

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

[akurka]

Hallo Mavarik und Himitsu
Ja Ihr habt recht, vermutlich habe ich zu früh gejubelt.
Es hat praktisch überall Warteschleifen, darum das zum Teil komische
verhalten.(anklicken mit der Maus löscht das Menü usw.)

Etwas verstehe ich nicht :
Wieso empfange ich auch in der Warteschleifen Meldungen von der
RSCOM ? Die RSCOM benützt WinAPI, sind das bereits ein Threads ?

Aber die RSCOM unit ist kein Thread ???
Muss ich die in dem Fall als ein Thread ausführen ?
Ich habe mich noch nie einen Thread versucht, ja nu, es gibt immer das
erstemal.

Es wird in allen diesen Warteschleifen auf irgendeine Message vom
rs232 gewartet oder auf eine TastaturEingabe.
(Maus Events werden keine benötigt)

Das bedeutet, ich müsste in jeder Schleife das Application.ProcessMessage aufrufen,
wäre das so richtig ?

Vielen Dank.
Gruss Anton

[Mavarik]

Ich kenne die RSCom jetzt nicht, aber

Ich würde auf jeden Fall eine RS232 Routine verwenden, die einen Event auslösen kann, wenn Informationen an liegen...
Das kann ggf. natürlich auch ein eigener Thread sein, der in einer Endlosschleife darauf wartet...

Immer wenn der Event dann feuert: OnRSDataReady.. wird die Information dann verarbeitet.

Bedeutet: Dein Programm funktioniert Event gesteuert und ist im Prinzip die ganze Zeit im Idle-Mode...

Mavarik

[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
Anhang 41161

Mit ein paar simplen

Delphi-Quellcode:

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.

[Sir Rufo]

Ich habe mal ein ganz simples Beispiel-Programm geschrieben was hierzu passt.

Zentrales Element ist diese Unit hier

Delphi-Quellcode:

unit Container_Data;

interface

uses
  Classes,
  SyncObjs;

type
  TData = record
    Value1 : Integer;
    Value2 : Integer;
    Value3 : Integer;
  end;
  
  TDataContainer = class
  private
    FCS : TCriticalSection;
    FData : TData;
    function GetData : TData;
    procedure SetData( const Value : TData );
  public
    constructor Create;
    destructor Destroy; override;

    property Data : TData read GetData write SetData;
  end;

  // Daten-Sammler
  TDataThread = class( TThread )
  private
    FContainer : TDataContainer;
  protected
    procedure Execute; override;
  public
    constructor Create( AContainer : TDataContainer );
  end;

implementation

{ TDataContainer }

constructor TDataContainer.Create;
begin
  FCS := TCriticalSection.Create;
  inherited Create;
end;

destructor TDataContainer.Destroy;
begin

  inherited;
  FCS.Free;
end;

function TDataContainer.GetData : TData;
begin
  FCS.Enter;
  try
    Result := FData;
  finally
    FCS.Leave;
  end;
end;

procedure TDataContainer.SetData( const Value : TData );
begin
  FCS.Enter;
  try
    FData := Value;
  finally
    FCS.Leave;
  end;
end;

{ TDataThread }

constructor TDataThread.Create( AContainer : TDataContainer );
begin
  inherited Create( False );
  FContainer := AContainer;
end;

procedure TDataThread.Execute;
var
  LData : TData;
begin
  inherited;
  LData := FContainer.Data;
  while not Terminated do
    begin
      case Random( 3 ) of
        0 :
          LData.Value1 := Random( 101 );
        1 :
          LData.Value2 := Random( 101 );
        2 :
          LData.Value3 := Random( 101 );
      end;
      FContainer.Data := LData;
      Sleep( Random( 30 ) );
    end;
end;

end.

Der Thread nimmt irgendwelche Zufallsdaten, trägt diese in den Record ein und übergibt diesen Record dem Container.
Der Container regelt den Zugriff auf diese Daten von unterschiedlichen Threads mit einer CriticalSection.

Die Form zum Anzeigen nimmt sich jetzt per Timer (50ms) die Daten aus dem Container und stellt diese dar.

Delphi-Quellcode:

unit UI_Form_Data;

interface

uses
  Windows, Messages,
  SysUtils, Variants, Classes,
  Graphics, Controls, Forms, Dialogs, StdCtrls, ExtCtrls,
  UI_Form_Base, Container_Data, Vcl.ComCtrls;

type
  TUIData_Form = class( TUIBase_Form )
    RefreshData_Timer : TTimer;
    Value1_Label : TLabel;
    Value2_Label : TLabel;
    Value3_Label : TLabel;
    Value1_ProgressBar : TProgressBar;
    Value2_ProgressBar : TProgressBar;
    Value3_ProgressBar : TProgressBar;
    procedure RefreshData_TimerTimer( Sender : TObject );
    procedure FormClose( Sender : TObject; var Action : TCloseAction );
  private
    FContainer : TDataContainer;
    procedure SetContainer( const Value : TDataContainer );
    procedure PresentData( AData : TData );
  public
    property Container : TDataContainer read FContainer write SetContainer;
  end;

var
  UIData_Form : TUIData_Form;

implementation

{$R *.dfm}
{ TUIData_Form }

procedure TUIData_Form.FormClose( Sender : TObject; var Action : TCloseAction );
begin
  inherited;
  Action := caFree;
end;

procedure TUIData_Form.PresentData( AData : TData );
begin
  Value1_Label.Caption := IntToStr( AData.Value1 );
  Value1_ProgressBar.Position := AData.Value1;
  Value2_Label.Caption := IntToStr( AData.Value2 );
  Value2_ProgressBar.Position := AData.Value2;
  Value3_Label.Caption := IntToStr( AData.Value3 );
  Value3_ProgressBar.Position := AData.Value3;
end;

procedure TUIData_Form.RefreshData_TimerTimer( Sender : TObject );
begin
  inherited;
  PresentData( FContainer.Data );
end;

procedure TUIData_Form.SetContainer( const Value : TDataContainer );
begin
  if Value = FContainer
  then
    Exit;

  FContainer := Value;
  RefreshData_Timer.Enabled := Assigned( FContainer );
end;

end.

Natürlich kann man hier jetzt auch eine Benachrichtigung einbauen, wenn sich die Daten ändern und nur dann zeichnen lassen. Grundsätzlich geht es aber erstmal darum, das generelle Konzept der Events mit möglichst einfachsten Mitteln zu zeigen.

Im Anhang das gesamte Projekt (ich hoffe das läuft so unter Delphi 7 - hab leider keins da um das zu testen, alle Namespaces habe ich aber eigentlich entfernt)

[akurka]

Hallo Sir Rufo
Ja ich habs ja nicht behauptet das es anders ist.
Tatsächlich ist es eine 20 Jahre alte DOS applikation, ursprünglich
in MS-Pascal geschrieben, ich war damals u.a. auch beteiligt.
Nun ich betrachte dies als mein persönliches Hobby, das alte Programm umzuschreiben (ohne Rücksicht auf Stunden Aufwand)

Leider ist es so, dass ich mich die letzte 15 Jahre hauptsächlich mit
FPGA (VHDL) Entwicklungen beschäftigt habe und damit den Anschluss an
OOP programmieren völlig verpasst habe.

Nun will ich aufs Alter meine Sünden aus der Vergangenheit wieder
gutmachen.Wie es halt so ist, man probiert immer der Weg des geringsten Widerstandes.
Das es leider mit der hergeholten COMPORT
Funktionen nicht so funktioniert ist mir jetzt langsam auch klar.
Das ist jetzt auch mein Ziel die RSCOM Unit neu zu gestalten.
Oder weisst Du eine geeignete Komponente die ich da für die
rs232 einsetzen kann ?
Gruss Anton

[Sir Rufo]

Eine Empfehlung habe ich da nicht, es sollten sich aber so einige über Tante google finden lassen.

Für die Umstellung von Konsole auf GUI ist das aber auch erstmal nebensächlich wie die Daten konkret geholt werden. Du musst das GUI-Konzept mit den Events erst mal verinnerlichen (siehe mein Beispiel-Projekt).
Das sehe ich hier gerade als größere Baustelle.

Dann kannst du im Anschluss auch die konkrete Kommunikation anbauen.

Beim Arbeiten mit OOP ist eine Grundlage auch die Abstraktion, somit passt das als Übung auch, die konkrete Kommunikation mit RS232 zunächst aussen vor zu lassen ;)

[vagtler]

http://www.tmssoftware.com/site/async32.asp

[akurka]

Hallo Sir Rufo

Vielen Dank für das Programmbeispiel. Leider konnte ich es
nicht laufenlassen, da es im ContainerData beim Sleep
mit kompilieren hängen bleibt.

Nach dem ersten Durchsicht Deines Beispiels würde es für mich bedeuten, dass Bestehende komplett über Bord zu werfen und neu anzufangen.
Da, wenn ich es dann erlebe, werde ich noch 85 Jahre alt(jetzt 75).Das Jetztige Programm war 6 MannJahre.

Ich muss zuerst erwähnen, dass der bisherige Programm 16 Menüs hat, mit jeweils einigen Untermenüs. Das was Du gesehen hast, ist nur ein sehr kleine Teil des Ganzen.

Die Kommunikation geht nicht nur in der Richtung
CNC => PC sondern auch umgekehrt PC => CNC.
Also möchte ich es nicht allzu puristisch betrachten, sondern pragmatisch der kritischste Problem von COM Schnittstelle lösen.

Da die Eingabe von z.bsp Koordinaten sich ohne weiteres
mit Delphi konformen Mittel gewährleisten lässt, bleibt
nur die COM Schnittstelle die als thread laufen muss ( da bin ich mit Dir vollkommen einig).
Und die Schnittstelle ist es auch, die mir offenbar alle die Folge-Probleme bereitet(wie KeyPress).

Und es geben prinzipiell nur zwei mögliche Events :
1: Meldungsinhalte die von CNC kommen (sind in globalen
variablen (records) gespeichert(durch RSCOM).
(in der Beilage die globale Var.Deklaration und jetztige EmpfangsProcedur(getblk)als Bsp.)
2: Eingabe der Koordinaten oder Einzelzeichen (Funktionstasten), es wird keine Maus gebraucht.

Schon das alte Programm dürfte nicht stehen bleiben,damals hat man es mit timeouts gelöst, was heute
sicher anders lösbar ist.
Es gibt also auch eine Variante das Ganze mit WinCRT/WinGraph funktionen zu lösen, (also gar nicht OOP),mit Ausnahme von einem Menue braucht es lediglich nur Linien.
Soviel zum gesamt Problem.
Gruss Anton

[akurka]

Hallo vagtler
Danke für den guten Tipp wegen async32, nach dem erstem Durchsicht ist es das, was ich benötige.
Gruss Anton

[Sir Rufo]

Unter Delphi 7 sollte

Delphi-Quellcode:

Sleep

eigentlich bekannt sein und sich auch in der Unit

Delphi-Quellcode:

SysUtils

befinden.

Was für einen Fehler bringt der Compiler denn?

Du kannst auch versuchen die Zeile komplett rauszunehmen (ist eh nur eine kleine Bremse für den Thread) ;)

Der Vorteil von OOP (fällt dir mit den Forms eh schon vor die Füße) ist neben Abstraktion und Vererbarkeit auch der klar definierte Kontext und die Möglichkeit Zugriffe zu beschränken (nur lesende Eigenschaften) oder auch zu schützen (Eigenschaften mit Getter und Setter, die per CriticalSection die Zugriffe thread-sicher gestalten) den man bei globalen Variablen nur beschränkt - niemals sicher - und nur mit sehr viel Disziplin hinbekommt.

Ich möchte es dir aber nur schmackhaft machen und nicht aufdrängen.

[akurka]

Hallo Sir Rufo
Vielen Dank, Du rennst offene Türe ein,
überzeugt von OOP bin ich schon, aber ich muss auch realistich sein, und einen
vernüftigen Kompromiss finden zwischen Gebastel und OOP programmieren.

Ich kann mir vorstellen, dass es einem OOP Spezialist graut, wenn er so etwas
hört.

Habe neben dem Programmieren aber auch noch ganze Menge
andere Hobbys und die wollen auch noch gelebt werden.

Jetzt werde ich zuerst das vom vagtler erwähnte async32 mal testen.
Hast Du vielleicht Erfahrung damit ?

Sonst muss ich mal selber etwas probieren.
Gruss Anton

[Sir Rufo]

Mir graut es nicht, ich kann es nachfühlen, da ich selber von BASIC, Pascal und dann auf Object-Pascal umgestiegen bin. Es dauert, bis man die Gedankenwege OOP-konform bekommt :)

Nein, Erfahrungen habe ich damit nicht.

[akurka]

Hallo Sir Rufo

Wir haben miteinandern kürzlich Meinungen ausgetauscht in Zusammenhang mit dem Umschreiben von älteren Pascal Programmen.
Ich habe in letzte Zeit versucht mich ein bisschen in die Materie einzuarbeiten. Wie dem auch so ist, aller Anfang ist schwer.
Darum möchte ich Dich fragen, ob Du bereit wärst, mir ein bisschen unter die Arme zu greifen .
Ich habe versucht Dich privat zu erreichen aber das ist offenbar nicht möglich.
Falls es Dich interessiert ist in der Beilage die Beschreibung
der Gesamtfunktion.
D.h. vor allem bei der Gesamtstruktur ist es sehr schwer ein richtigen Kompromiss zu finden zwischen einerseits reine OOP und
andererseits möglichst wenig Aenderungsaufwand für bestehende (Pascal) Programm Teile.
Und ich denke, wenn am Anfang die Gesamtstruktur nicht stimmt, rächt sich das später.

Für die Bedienung der RS232 gibt es die Komponente "TMS_Asyc32" die Erreignis gesteuert ist.

Ich habe angefangen die einzelne Methoden aus diese Komponente auszutesten (onCTS,OnRX..), das funktioniert soweit.

Je nach Meldungsinhalt sollen dann unterschiedliche Units(Forms) starten, da ist es mir nicht ganz klar wie man es
lösen soll, es darf ja im prinzip keine warteschlaufe geben, oder ?

akurka@bluewin,ch
Mit freundlichen Grüssen
Anton