4. TForm kein eigenständiger Thread????

TForm kein eigenständiger Thread????

  • S

    Servus.

    Telegrammstil um keinen ROman zu verfassen:

    Ich habe eine Formular Anwendung laufen. Im MainForm wird ein TThread erstellt. Dieser Thread (Controller) startet einen weiteren TThread (Motor).

    Beide laufen mit
    Execute()
    {
    while(!Terminated)
    {
    WaitForMultipleObjects(x,x,x,x);
    ....
    Initialize();
    ....
    }
    }

    als Zustandsautomaten.

    Nun habe ich ein weiteres Formular erzeugt. Das dient mir als Simulations Oberfläche des Motors. Im MainForm wird ein Button gedrückt. Event an Controller INITIALISIERE. Controller läd seine Ini Dateien. Schickt Event an Motor. INITIALISIERE. Motor läd seine DAteien. Simulation ist aktiv.

    Membervariable vom Motor --> Simulationsoberfläche. TForm steht stellvertretend für den Klassennamen.
    Also
    TForm* sim_vis.

    sim_vis = new TForm(Application);
    sim_vis->Show();
    Ok alles klar. Controller läuft weiter Code ab ... springt wieder in WaitForM.....

    Simulationsoberfläche ist da. Die Elemente darauf nicht. Alles hängt.`....

    HILFE?

    0
  • S

    Mhhh ich hab nun ein wenig rumprobiert.

    TForm erzeugt.
    TForm erzeugt einen TThread.
    TThread erzeugt ein TForm.

    Wenn TThread einschläft, dann schläft Form ein.

    TForm erzeugt.
    TForm erzeugt ein weiteres TForm.

    Das 2. TTform wird mit einem Sleep angehalten --> Alles steht.

    Ich dachte mit Show wird ein Formular so angezeigt, daß alles weiterläuft.
    Und ich dachte ein Formular IST ein Thread. Dem scheint nicht so?

    Kann mir da mal einer weiterhelfen? Ich möchte mehrere Formulare/Dialoge, die slebstständig laufen ohne die restliche Anwendung anzuhalten...

    0
  • A

    Hallo

    Shogun schrieb:

    TForm erzeugt.
    TForm erzeugt ein weiteres TForm.

    Das 2. TTform wird mit einem Sleep angehalten --> Alles steht.

    Ich dachte mit Show wird ein Formular so angezeigt, daß alles weiterläuft.
    Und ich dachte ein Formular IST ein Thread. Dem scheint nicht so?

    Nein die Forms sind nicht eigene Threads, sondern vom Thread abhängig in dem sie erzeugt werden. Wenn du also im Hauptform einfach ein zweite Form erzeugst wird ein Sleep im zweitem Form auch das Hauptform anhalten.
    Lösung ist überhaupt kein Sleep in einem Form zu verwenden sondern in Threads auszulagern. Dann kannst du nichtblockierende Forms verwenden.

    bis bald
    akari

    0
  • ?

    Nein, ein TForm ist kein eigenständiger Thread. Kann ja auch nicht, sonnst müsstest einen sehr hohen Aufwand betreiben, um Daten zwischen Forumoaren auszutauschen. Alle TForms laufen (standardmäßig) im Kontext der Application.
    Ehrlich gesagt, bin ich noch nicht auf die Idee gekommen, aus einem Thread heraus ein Form zu erzeugen. Widerspricht auch eigentlich dem Sinn eines Threads. Threads verwendet man um im Hintergrund, unabhängig von dem GUI, arbeiten durchzuführen.

    Grüße Joe

    0
  • S

    Mein Problem ist zur Zeit einfach, daß ich eine Anlagensteuerung schreibe.

    Die aht eine GUI.

    Geplant ist dann später mal das Trennen der Steuerung von der GUI. Sprich die steuerung soll auch ohne Oberfläche alleine laufen. DEswegen trenne ich schon Optionen etc. Ich versuche möglichst wenig Abhängigkeit untereinander zu schaffen.

    Die Steuerung besteht aus einem Controller Thread. Dieser wieder hat 4 andere Threads. EIner macht die IO, einer die BV, einer die Motor Ansteuerung und einer die Kamera Ansteuerung.

    Die Threads sind als Zustandsautomaten aufgebaut. Das habe ich über eine while Schleife gelöst in der ein Wait for Events drin ist. Ein Event löst dann den Übergang aus. Also TERMINATE, INITIALIZE und beispielsweise BEGIN_CAPTURE oder START_MEASUREMENT. Die Threads arbeiten dann den Block ab.

    Nun gibt es aber auch eine Simulation. Bspsweise bekommt der Motor eine Anzeige, die dann einfach einen fahrenden Motor simuliert. Die Ein und Ausgänge der IO werden über Buttons und Checkboxen oder Radiobuttons simuliert.

    ABER diese Oberflächen sollen nicht in der GUI laufen sondern werden von den Threads gestartet.

    Ich wollte eigentlich auch diese Oberflächen von der GUI unabhängig machen... So daß ich die GUI austauschen kann, je nachdem was der Kunde wünscht. Aber ohne den Rest anfassen zu müssen.

    Die Threads führen ja die komplette Arbeit durch. Nur wollte ich eben die Anzeigen im Simulationsmodus nicht ins GUI packen.

    Wie lös ich das nun am Besten?
    Was mir jetzt einfällt ist, daß ich dann von den Threads aus eine Nachricht an die GUI schicke und die GUI die Simulations Forms anwerfen lasse.

    Eigentlich wollte ich derart extremes Zeiger umhergeschicke vermeiden...

    Im Simulationsmodus müssen ja die Threas in ihrer jeweiligen Oberfläche Elemente ändern oder auf Elemente reagieren.

    BSP:

    //in Form1.h
TForm2* form2;
TThreadX* thread;

BEGIN_MAP
//Message definieren
END_MAP (TForm)

//in Form1.cpp
thread = new TThreadX(false,this);

.....
....
//in der EReignisbehandlungsroutine für CREATE_FORM2
form2 = new TForm2(Application);
form2.Show();
//dem Thread den pointer zukommen lassen

//in Execute von TThreadX

while.....
{
....
result=WaitForMultipleObjects(.....);
//Event wird gesetzt
//Abarbeitung für dieses Event
switch (result)
{
case xyz : {
PostMessage(pform1,CREATE_FORM2);
//
break;
}
case zyx : {
//so jetzt muss dem thread wieder die Adresse von form2 bekannt gemacht werden in der Zwischenzeit....
pform2->Label1->Caption="blubber";
default: ....
}
}

    Das ist doch ein riesen Bandwurm oder?

    0
  • ?

    Vorab: Oberfläche == GUI (Graphical User Interface).

    Grundsätzlich der sinnvollste Weg wäre, den Threads einen Zeiger auf ein Formular zu übergeben, welches für die Datenanzeige des Threads zuständig ist. Über diesen Zeiger kannst Du dann Nachrichten an das Formular senden, die dann die Änderungen an Zuständen signalisieren und im Form grafisch dargestellt werden. In den Formularen mußt Du natürlich Behandlungsroutinen für die diversen Nachrichten schreiben.

    0
  • S

    Sorry hab ich erst beim Tippen gemerkt.

    Meine Hauptanzeige nennt sich GUI_irgendwas. Damit meine ich mein MainForm quasi.

    Die Software muss halt irgendwann komplett ohne laufen. Diese Oberfläche soll austauschbar sein. Wenn ich die Simulationsoberflächen in dieser Oberfläche schaffe, so erschwere ich mir das. Jede Variable, die der Controller und die GUI mehr teilen, ist eine SChnittstelle mehr, die ich handeln muss....

    Die eigentliche Arbeit erledigen ja die 5 Threads. Die Kommunikation mit der Oberfläche macht nur der Controller.

    Moment ich mach mal ein Bildchen.

    Linke zum Diagramm

    So wie das Obere wollte ich egentlich die Kommunikation. Das Untere sollte die Beziehung der Objekte sein. Also G_UI legt Controller an, Controller legt die Threads an, Threads legen ihre Simulationsoberfläche an.

    EDIT: Kein Image Tag? Naja ok....

    0
  • ?

    Die Sim-Oberflächen gehören zum GUI, Du hast sie allerdings als eigene Entitäten. Das ist das Problem. Ob das nun eine Simulations-GUI oder ein Steurungs-GUI, oder einfach eine darstellende GUI ist, ist dabei irrelevant.

    0
  • S

    MEinst also ich soll mir das Variablen jonglieren antun und die SIMs in die Hauptoberfläche packen. Rein Objektmässig. Und das Starten dann eben über eine Message anleiern.

    Dumm ist dann halt nur die Kommunikation mit den Dingern. Das heisst ich muss JEDEM Thread das MainForm als ADresse geben (Wegen der MEssage) und nochmal jedem Thread die Adresse "seines" Formulars.

    Wobei der Controller ja eigentlich sowieso die Adresse des MainForms hat... Also kann der Controller da auch die Adressen der anderen Formulare rausholen und an die Threads verteilen.

    Puh die Abhängigkeiten wollte ich eigentlich reduzieren...

    Bedeutet dann also, daß ich das ganze von der reinen Definition her schon so aufbauen MUSS, daß die Software ohne GUI auch ohne Simulation ist. Knallhart.

    Also ENTWEDER reine Funktionalität, also nur die Threads in einer Anwendung. ODER eine Oberfläche, die auch Simulationsoberflächen beinhaltet.

    Sorry für die Umgangssprache. Aber ich bin schon wieder leicht gestresst 😃 Ich muss den kompletten Grundaufbau der Software in 7 Tagen erledigen. Ich habe noch 2 oder 3.

    0
  • ?

    Nicht notwendigerweise. Die Kommunkation zum MainForm sollte ausrechen. Von dort kannst Du bestimmte Nachrichten an die entsprechenden Forms weiterreichen.
    Die Unterscheidung kannst Du entweder am Botschaftstyp selbst durchführen, oder Du verwendest einen der Parameter zur Unterscheidung.

    0
  • A

    Hallo

    Dumm ist dann halt nur die Kommunikation mit den Dingern. Das heisst ich muss JEDEM Thread das MainForm als ADresse geben (Wegen der MEssage) und nochmal jedem Thread die Adresse "seines" Formulars.

    Das muß ja nicht direkte Abhängigkeit sein. Für sowas ist das Observer-Pattern gut geeignet. Damit wird erreicht das ein Objekt Meldungen an ein anderes schickt ohne das sich beide genau kennen müßen. Damit kannst du GUI und Logik (Threads) miteinander koppeln ohne das wirklich eine Abhängigkeit besteht.

    bis bald
    akari

    0
  • S

    Hmmm Nachrichtentyp? Wie meinst du das Joe?
    Mein Problem ist ich traue Messages nicht so. Bin mit da nie ganz sicher ob die wirklich in der Reihenfolge abgearbeitet werden, wie ich es will.

    Ich habe mir beispielsweise in den letzten Wochen einen Logger gebaut, der einen Thread laufen hat, an den ich schicke... Das ist im Grunde ein TForm, das einen Thread startet. Der liest quasi einen Ringspeicher aus, den ich über eine Funktion fülle. Der Thread wartet quasi bis über die Funktion ein Event gesetzt wird, daß was geschrieben wurde. DAnn liesst der Thread den Speicher aus und über Synchronize schreibt er ins Formular in einen Puffer und ein ListView.Keine Messages. Und jetzt muss ich feststellen, daß ein Form gar kein eigenständiger Thread ist... Da hab ich irgendwo wohl mal was falsch verstanden. Naja gut es ist ja nicht unbedingt schlimm. das Empfangen handelt ja ein Thread. Das Weiterleiten und in ein TListView schreiben passiert ja vom Thread aus... bullshit... 6 oder 8 Wochen hab ich daran gebastelt... Zig Tage debuggt und gebastelt, damit alle Nachrichten ankommen.

    Dieser Logger wird übrigends auchvom MainForm erzeugt...

    Egal zurück zu den Messages... Scheisse... Ich glaub ich mach heut früh Feierabend... Ich schreibe meine Diplomarbeit, hab noch 2 1/2 Wochen eine komplette Software aufzubauen...
    VERZWEIFLUNG

    @akari: Klingt interessant. Befürchte aber ich habe nicht mehr die Zeit da groß zu testen. Mal eben fertig lesen.

    DAMNED... Ich verzweifel hier...

    Ich versuche jetzt irgendwie die Grätsche zu bekommen.Ich bin halt mal kein Informatik Student sondern eigne mir das alles selbst an. Ich bin Bildverarbeiter und Optotechniker.

    0
Anmelden zum Antworten