Autor Beitrag
Christoph1972
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 690
Erhaltene Danke: 16


VS2015 Pro / C# & VB.Net
BeitragVerfasst: Do 22.01.09 21:31 
Hallo zusammen,


ich habe eine KLasse, mit dieser empfange ich Daten über RS232. In der Main Form übergebe ich die Daten mittels Delegate an ein Steuerelement. Das funktioniert auch so weit. Nur dann und wann, wenn die Application bei geöffnetem Port geschlossen wird, gibt es eine Exception: Auf das verworfene Objekt kann nicht zugegriffen werden. OK, ich habe mir gedacht, das ich dann einfach den Port im FormClosing schließe. Aber auch das hilft nicht. Hat hier jemand einen Tipp, oder eine Idee, wie ich das abfangen kann?


ausblenden C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
private void InvokeValue(String Data)
        {
            if (InvokeRequired)
            {
                        
                Invoke(new DelegateVoid(InvokeValue), new object[] { Data });// Hier der BUG! Auf das verworfene Objekt kann nicht zugegriffen werden.   
            }
            else
            {
                txtValue.Text = Data;
            }
        }



Gruß
Christoph
Christian S.
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 20451
Erhaltene Danke: 2264

Win 10
C# (VS 2019)
BeitragVerfasst: Do 22.01.09 21:38 
Ich übersetze "verworfen" jetzt einfach mal mit "Disposed", bin mir aber nicht sicher, ob das stimmt. ( Ich mag englische Entwicklungsumgebungen :D )

Falls die Übersetzung richtig ist, würde ich auf (!(this.IsDisposing || this.IsDisposed)) prüfen.

//edit: Du solltest da aber noch irgendwie mit einem Mutex sicherstellen, dass zwischen der Abfrage und dem Invoke nicht gerade geschlossen wird.

_________________
Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
Christoph1972 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 690
Erhaltene Danke: 16


VS2015 Pro / C# & VB.Net
BeitragVerfasst: Do 22.01.09 21:43 
Hi :-)

Ja, ich meine Dispose. An welcher Stelle würdest du den die Prüfung vornehmen? Direkt vor dem Invoke? Ist halt blöd zu debuggen, da der Fehler ja nicht immer auftritt. Ich dachte das der Fehler mit dem schließen, des Ports behoben sei. Das es nicht so ist, habe ich erst zwei Tage später bemerkt.



Gruß
Christoph
Christian S.
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 20451
Erhaltene Danke: 2264

Win 10
C# (VS 2019)
BeitragVerfasst: Do 22.01.09 22:00 
Ich hoffe, ich hau da jetzt nicht daneben. Bei solchen Geschichten muss ich meist ein paar Mal nacharbeiten. Kann's Dir leider auch nur in Delphi Prism geben, sollte sich aber 1:1 in C# umsetzen lassen (ist ja beides .NET nur andere Syntax):

ausblenden Delphi Prism Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
fMutex : Mutex := new Mutex; //privates Feld

(* ... *)

method MainForm.MainForm_Load(sender: System.Object; e: System.EventArgs);
begin
  async loop begin //Eine Schleife, welche den Daten-Eingang simuliert und in einem separaten Thread läuft
    Thread.Sleep(1000);

    fMutex.WaitOne; //Mutex reservieren
    if not (self.IsDisposed or self.Disposing) then //Form noch "benutzbar"
    begin
      Invoke(methodbegin
        label1.Text := DateTime.Now.Ticks.ToString;
      end);
    end;
    fMutex.ReleaseMutex; //Mutex freigeben
  end;
end;

method MainForm.MainForm_FormClosing(sender: System.Object; e: System.Windows.Forms.FormClosingEventArgs);
begin
  fMutex.WaitOne; //Mutex holen
end;


Bei FormClosing gebe ich den Mutex extra nicht mehr frei, weil ab dann ja möglichst die asynchrone Operation nix mehr tun sollte. Das WaitOne im Thread dürfte diesen dann aber blockieren, da musst Du mal schauen, ob das stört.

So, hoffentlich sind da keine großen Schnitzer drin, war ja ein langer Tag :gruebel:

_________________
Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
Christoph1972 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 690
Erhaltene Danke: 16


VS2015 Pro / C# & VB.Net
BeitragVerfasst: Do 22.01.09 22:22 
OK, Vielen Dank! Ich werde es mal versuchen!


Gruß
Christoph
Christoph1972 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 690
Erhaltene Danke: 16


VS2015 Pro / C# & VB.Net
BeitragVerfasst: Do 22.01.09 23:37 
Hm, Problem besteht immer noch. Die Prüfung hat keine Wirkung. Ehrlich gesagt ist mir aber nicht klar warum. Das Problem tritt mal in der Klasse, dann mal wieder in der Main Form auf. Wenn ich die RS232 Schnittstelle in der Main Form implementiere, passiert das nicht. Vielleicht hilft es ja doch, wenn ich das Invoke gleich in der Klasse ausführe :gruebel:


So, erst mal drüber schlafen......



Gruß
Christoph
Christoph1972 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 690
Erhaltene Danke: 16


VS2015 Pro / C# & VB.Net
BeitragVerfasst: Mo 26.01.09 22:54 
Hallo Leute,


Super, ich habe den Fehler gefunden. Ist mir kaum peinlich :oops:

Ich habe im DataReceived Event zweimal die ReadLine Funktion aufgerufen. :gruebel:

ausblenden C#-Quelltext
1:
2:
3:
4:
5:
6:
TestVar = SPort.ReadLine();

if (GetValue != null)
{
 GetValue(this, SPort.ReadLine());
}


Wenn ich den Serial Port geschlossen habe, bevor die TestVar einen Wert erhalten hat, dann knallt es bei dem Aufruf des Events. Wenn ich das Schließen nach der Wertzuweisung von TestVar aufgerufen habe läuft die Funktion bis zum Ende durch. Tja und warum rufe ich ReadLine zweimal auf? Weil ich Blödmann vergessen habe die Zeile mit TestVar zu löschen. :autsch:


Schön wenn man sich wegen so einem Mist den Kopf zerbricht. Ich hoffe, das keiner von euch all zu viel über dieses Problem nachgedacht hat!

Vielen Dank für eure Hilfe!!!!!



Gruß
Christoph