Hallo,

ich beisse mir aktuell an einem etwas merkwürdigen Problem die Zähne aus und hoffe nun hier Anregungen/Tipps zu bekommen, die mich der Lösung etwas näher bringen.

Folgende Situation:

2x MDI-Formulare
1) enthält im Wesentlichen ein TStringGrid und ein TListView.

Das Ganze funktioniert als Debugger für eine SPS, im Stringgrid wird der Code angezeigt und in der rechten Spalte Informationen zum aktuellen Zustand/Werten von Symbolen, etc.
Im Listview können Symbole zur Beobachtung definiert werden.

Die Daten werden durch einen Hintergrundthread aktualisiert, der dem Formular signalisiert wenn neue Daten vorliegen, so dass die Ansicht aufgefrischt wird.

2) enthält ein Editfenster, in dem der AWL-Code bearbeitet wird.

Als Editorkomponente kommt ein TSynEdit (aus dem UniSynEdit) zum Einsatz.

Nun das Problem:
Habe ich beide Fenster sichtbar und klicke im Stringgrid eine Zeile an, dann springt der Cursor in der SynEdit-Komponente auf dem anderen Formular ins Nirvana (vor die Zeilenangabe).
Klicke ich zurück in das Editorfenster wird der Cursor wieder entsprechend umgesetzt und bleibt dort.
Verschärft wird das Ganze noch, wenn ich mit dem Debugger Online bin, sprich laufend Daten aktualisiert werden. Dann spring der Cursor im Edit-Bereich wieder in die Wüste und lässt sich auch durch erneutes Klicken ins Fenster nicht dazu bewegen wieder normal zu funktionieren.
Das Ganze hängt offenbar zusammen mit der Verwendung von BeginUpdate/EndUpdate für die Datenspalte des StringGrids (.Cols[2].BeginUpdate/EndUpdate) bzw. das ListView.
Ich habe die entsprechenden Anweisungen jetzt mal auskommentiert und rechne auch nicht mit Performance-Problemen, aber das Problem mit dem Anklicken des StringGrids und dem vagabundierenden Cursor bleibt bestehen.

Hat jemand eine Idee, oder einen Ansatz woran das liegen könnte?

Wäre für jeden Vorschlag dankbar.

Crosspost DF

Kleines Update:

Meine Vermutung, dass mit TSynEdit was nicht stimmt hat sich nicht bewahrheitet. Ich habe das noch mit einem anderen Formular mit einem Standard-TMemo ausprobiert und erfahre da ebenfalls "Interferenzen".

Wie aktuallisierst Du im Thread, kann es sein das dort leere Daten geschickt werden?
Benutzt du das onchange der SysEdit. Sieht nach synchronisierungsprobleme aus, vermute ich mal.

Greifst Du evtl sogar Formübergreifend auf die Komponenten zu?

Zitat von CarstenB:

Kleines Update:

Meine Vermutung, dass mit TSynEdit was nicht stimmt hat sich nicht bewahrheitet. Ich habe das noch mit einem anderen Formular mit einem Standard-TMemo ausprobiert und erfahre da ebenfalls "Interferenzen".

hast Du dies getestet ohne Code, lediglich mit den Komponenten auf der Form?
Irgendwelche Einstellungen im OI gemacht?

Du siehst, Ist halt schwer da genau was zu sagen.

Nachtrag: Erstell mal ein neues Projekt mit den MiDIS und den Komponenten ohne zusätzlichen Code und irgendwelche Anpassungen im OI!

gruss alfold

Der Hintergrund-Thread läuft in einer DLL und erhält eine Callback-Funktion.
Um mir keine Probleme mit den Threading-Schwächen der VCL einzufangen macht der Callback nichts anderes als eine Nachricht an das Hauptformular zu schicken. Das ist zwar sicher keine Patent-Lösung, entkoppelt aber das Update von dem DLL-Thread (und es musste schnell gehen).

Diese Nachricht wird entgegengenommen und das Update der sichtbaren Daten (in zwei Schritten) durchgeführt.

1. Abholen/Puffern der Daten aus der DLL (wg. Performance, brauche die u.U. noch für Darstellung in FUP/KOP)
2. Update der sichtbaren Daten aus o.g. Puffer.

Formübergreifende Zugriffe gibt es in diesem Kontext nicht.

Ich werde mal ein Testprojekt basteln. Wenn das ohne Probleme funktioniert werde ich sukzessiv Code entfernen - habe ich zwar schonmal gemacht, aber in der Verzweiflung letzte Woche möglicherweise was übersehen.

Edit: Ich habe das Datenupdate mal komplett rausgenommen - gleiche Situation wie nach Entfernen der Begin/EndUpdates. Ich bekomme den Cursor wieder dahin wo er hingehört, wenn ich in das Textfeld, bzw. Memo klicke, aber sobald ich im Stringgrid was mache steht er wieder in der Wüste.

Kann es sein das Du evtl onchange und oncklick ähnliches ausführst und sich beide gegenseitig nerven?

alfold

So. Hier mal ein kleines Test-Projekt. Die .exe habe ich auch mit reingepackt, falls die Compiler-Umgebung eine Rolle spielen sollte. (Win7-x64)

Die Komponenten habe ich aus dem Original-Projekt kopiert um die Einstellungen komplett identisch zu haben - es passiert aber auch bei Original-Komponenten, die gerade aus der Toolpalette eingefügt wurden.

Toolbar hat 3 Funktionen:
1) Textformular öffnen
2) Formular mit Grid öffnen
3) horizontal anordnen

Klickt man im Grid auf Zeile 8 und aktiviert (per Titelzeile) das Textfenster ist der Cursor unterhalb der letzten Zeile, bei Klick auf Zeile 5 im Grid steht er anschliessend zwischen Zeile 6 und 7 im Textfeld.

Edit: Habe mal noch einen Timer + Ein/Ausschalter eingebaut. Sobald dieser läuft und die "Debugdaten" aktualisiert spinnt der Cursor im anderen Fenster komplett. Man schreibt zwar an der richtigen Stelle, aber es blinkt woanders.

Schöner effekt
Spass beiseite, was mir auffällt ist die unterschiedlich Schriftgrösse!
Sollte aber normalerweise kein Grund sein den Cursor falsch zu platzieren, aber wer weiss?

kann aber erstmal nichts machen(in mein delphi7 anzupassen) muss weg leider.
erst 2300 zurück

Edit:
Hab mal was gemacht und ich hab mit meiner simplen Lösung kein Problem!
Hier mal Code wie ich von Grid zu Richedit es umgesetzt habe

zusammenfalten · markieren

Delphi-Quellcode:

//------- dies habe ich in frmText mal eingwefügt
procedure TfrmText.FormCreate(Sender: TObject);
var
  i: Integer;
begin
  for i := 0 to WantLines -1 do
   rceText.Lines.Add ('Zeile '+ inttostr(i+1));//<---hier hab ich mal +1 gemacht!
end
//-------- so setzt Du den Cursor--------
procedure TfrmText.SetRichLine(aRich: TRichEdit; aRichLine: Integer);
begin
    aRich.SelStart:= SendMessage(aRich.Handle, EM_LINEINDEX, aRichLine-1, 0);
end;
//----so kannst Du umgekehrt die Zeile im Richedit auslesen!
procedure TfrmText.GetRichLine(aRich: TRichEdit);
begin
    gridline := SendMessage (aRich.Handle, EM_LINEFROMCHAR, aRich.SelStart, 0);
end;

//zum test mal ein Timer eingesetzt
procedure TfrmText.Timer1Timer(Sender: TObject);
begin
    SetRichLine(rceText, myline);
end;
//-------------------------------------//


//------dies in frmgrid-------------
procedure TfrmGrid.grdCodeClick(Sender: TObject);
begin
    myline:= grdCode.Row;
end;
//--------------------------------------//

myline <---ist Ausnahmsweise mal ne globale Variable in der Mainform

Wie gesagt so funct es bei mir ohne probleme!

gruss alfold

Danke für deine Mühen , aber das löst leider nicht das Problem.

Es ist nicht das Ziel bei Klick auf eine Zeile im Debugger die entsprechende Quellcode-Zeile im RichEdit anzuspringen. Das ist ausserhalb dieses Testprogramms ohnehin nicht so einfach, da in AWL i.d.R. diverse andere Dateien mit eingebunden werden. Da geht die Ermittlung von Quelldatei und -zeile über Querverweislisten, etc.

Die Frage ist für mich einfach, warum es überhaupt eine Auswirkung auf das TRichEdit, TSynEdit oder sonstwas hat, wenn ich bei gleichzeitig sichtbarem StringGrid auf einem anderen Formular dort hineinklicke. Das dürfte m.E. einfach nicht passieren.

Ich bin beruhigt, dass ich wohl nicht der Einzige mit diesem Problem bin.

QualityCentral

Werde den Workaround mal ausprobieren. Die Abfrage auf self.Focused einzubauen scheint mir Sinn zu ergeben.

Edit: Klappt jetzt.

Ach so, ich konnte aber in D7 WinXP SP3, diesen effekt als solches nicht nachempfinden.
Hat man in D2007 die Routine etwas verändert und schon funct es nicht

Aber der Link von @CarstenB scheint dies ja zu beheben

Gruss alfold