TImage friert ein, ich bin am verzweifeln

[alf.stefan]

Hallo Zusammen

In meiner Applikation (fireWire Kamera mit OpenGl) friert das TImage zum darstellen des Kamerabildes (Standbild mit Auswerte Grafik) nach ein paar updates ein.

Meine Frage ist jetzt wie kann ich so ein in TForm eingbundenes TImage wieder reinitialisieren?
Oder hat jemand eine Idee wie man solch einem eigenartigen Verhalten auf die Spur kommen kann?

Posten kann ich auch mein ganzes Projekt aber das ist ziemlich Hardware abhängig mit der Firewire Kamera und zur steuerung von dem ganzen läuft auch noch ein Threat der eine USB IO Platine ansteuert (Velleman usb experimental board). (btw: seit der usb threat mitläuft hat sich das problem verschärft.)


Wär schön wenn jemand ne Idee hätte wie ich weitermachen kann.

bis bald

Stefan

[Muetze1]

Ich sehe folgende mögliche Ursachen:

1. Hardwareproblem was die App hängen lässt und nicht das Image
2. Resourcenproblem, d.h. es werden alloziierte Bilder nicht wieder freigegeben und die App läuft "out of resources"
3. das zuweisen des Bildes löst ein OnChange oder anderen Notifier aus, welcher wiederrum auf das Image wirkt und somit eine Schleife produziert
4. Dein App ist nebenbei zuviel beschäftigt, so dass das TImage nicht mehr zum neuzeichnen kommt (bzw der VCL Thread)

[Bernhard Geyer]

Ich denke das du vermutlich von einem Thread auf das TImage zugreifst und das darf nur synchronisiert erfolgen!

[alf.stefan]

Prima da sind ja schon ein paar antworten.

@muetze 1. die App bleibt nicht hängen, die macht immer noch prima die Auswertung, das kann ich in einem Memo Feld checken in dem ein ergebnis String ausgegeben wird. die Aufrufe image.update, image.refresh und image.repaint and auch alle canvas zeichen befehle auf das image werden scheinbar ignoriert.


@muetze 2. meinest Du mit "alloziierte Bilder", dass ich die ganze Zeit TImage.Create aufrufe? Das mach ich nicht an so was hab ich auch schon gedacht und hab deshalb alles mit memCheck durchforstet und alle Speicherlecks geschlossen.


@muetze 3. wenn ich das Bild nicht zuweise sondern immer mit dem einen TImage arbeite und das kein OnChange Ereignis zugewiesen bekommen hat. Komm ich da auch in dso ne Schleife?

@muetze 4. dafür dass die App zuviel beschäftigt spricht meiner Meinug nichts. Im Taskmanager werden grade mal 10% Rechenzeit verbraten.


@Bernhard Geyer ja beim Livebild darstellen mach ich das auch in einem separaten threat aber um das Bild abzudaten benutz ich schon sync.

Delphi-Quellcode:

  repeat
    ...
   synchronize(updateImage);
    ...
  until terminated;  

procedure TCamDisplay.updateImage
begin
    try
      camera.display(self.image);
    except
      self.terminate;
    end;
end;
end.

[Ferdy2003]

Ich hatte auch mal so ein Problem bei einem Programm von mir. Ich hab es wie folgt gelöst:

Delphi-Quellcode:

Image.Picture.LoadFromFile(lokal); //Bild laden
     Image.Visible := false; //Bild unsichbar schalten
     Image.Visible := true; //Bild wieder sichtbar schalten

Durch diesen Trick hat er bei mir immer das neu zugewießene Bild angezeigt.

Gruß

Ferdy2003

[alf.stefan]

@Freddy2003 Habs probiert mit visible toggeln aber dann seh ich nur den Grauen Hintergrund des TForm.

Wie kann man eigentlich schauen wie stark ein Threat die App beansprucht?

Kann das eigentlich auch mit meiner ActionList zusammenhängen mit der ich die Steuerung umgesetzt habe.

im USb Threat rufe ich wenn das entsprechende Signal kommt TAction.Execute auf die dann im Hauptthreat abgearbeitet wird.

hauptthreat

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    Image1: TImage;
    actPic: TAction;

Delphi-Quellcode:

var
  Form1: TForm1;
  camServ : TCamServer;
  ioThreat : TUsbIoThreat;

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin
      Camserv := TCamserver.create(Form1);
      CamServ.Image1 := nil;
      CamServ.parentApp := Application;
      CamServ.displayPanels[0] := nil;
      CamServ.displayPanels[1] := nil;
      CamServ.memo := Memo1;

      if Camserv.disp1 <> nil then
      begin
        CamServ.disp1.Terminate;
        CamServ.disp1.WaitFor;
        CamServ.disp1.Free;
      end;

      ioThreat := TUsbIoThreat.Create(True);
      ioThreat.usbOutPut :=0;
      ioThreat.inputChangedAction := actIoChange;
      ioThreat.usbSchrittkette := actChain;
      ioThreat.usbCardAddress :=0;
      ioThreat.usbStartAction:= usbStarted;
      ioThreat.usbRun := true;
      ioThreat.Resume;

und dazu im ioThreat

Delphi-Quellcode:

procedure TUsbIoThreat.Execute;
...

repeat
     if signalZumWeitermachen then usbSchrittkette.Execute; // also wird hier actChain aufgerufen!

until terminated

wenn jemand das ganze Projekt haben will um mein Problem besser zu verstehen kann ich ihm das schicken.


actChain ist TAction aus einer Actionlist in Form1!!


Kommen da vielleicht die resourcen durcheinander so ähnlich wie man synchronize benutzen soll???

Also die Kernfrage für mich ist " Kann man mit TActionList bzw. den TAction(s) einen Threat steuern? oder spricht da was dagegen?

[Robert Marquardt]

Kleiner Hinweis. Es heisst thread nicht threat. threat ist eine (Be)Drohung (bei USB threat stimme ich dir aber zu :)).

[alf.stefan]

@Robert Danke für den kleinen Hinweis.

Aber hat niemand eine Erklärung oder Anmerkung oder einfach eine Meinung zu der Aussage :

Ist es möglich von einem Thread aus eine TAction.Execute im Hauptthread auszulösen ohne was durcheinander zu bringen!

Freue mich auf Antwort

Stefan

[SirThornberry]

nein, jeglicher VCL-Zugriff muss syncron zum Hauptthread ablaufen bzw. im Hauptthread.

[alf.stefan]

VCL ist doch eine Visual Componente aber eine TAction doch nicht oder lieg ich da falsch.

Und wenn es mit TAction nicht geht wie löse ich denn dann ein Ereignis im Hauptthread von einem NebenThraed aus auf?

Und kann das der Grund für meine Probleme mit dem TImage sein??

Gruß

Stefan