C# Neue Form, neuer Thread (aber kein neues Glück)

[ML89]

guten Morgen,

ich bin mal wieder fleißig am Programmieren Dieses Mal möchte ich eine neue Form in einem Thread starten.
Das Anlegen und Starten eines neuen Thread mit meiner Form ist auch kein Problem, das habe ich geschafft:

Thread thread = new Thread(new ThreadStart(new Form().Show))
thread.Start();

Ich möchte, dass diese neue Form zwei Sekunden lang angezeigt wird und sich dann von selbst schließt.
So wie hier gezeigt schließt sich diese Form leider direkt.
Wie kriege ich das hin?

Danke schonmal

 

[Darlis]

Sobald ein Thread endet, werden auch dessen Ressourcen freigegeben, also in diesem Fall deine Form.
Die billige Variante: Du lässt den Thread 2 Sekunden länger leben.
Die richtige Variante: Du erstellst die Form im Hauptthread mittels Invoke, lässt deinen neuen Thread 2 Sekunden schlafen und schließt dann die Form wieder.
Warum du dafür einen neuen Thread brauchst verstehe ich aber nicht. Forms.Timer würde sich dafür besser eignen. Und warum nicht gleich WPF?

 

[ML89]

Also ich bin Programmier-Anfänger und habe bisher immer brav Windows Forms benutzt. Jetzt möchte ich mir nur kurz neben meinem Hauptprogramm eine Nachricht anzeigen lassen, die sich automatisch wieder schließt.

Die richtige Variante: Du erstellst die Form im Hauptthread mittels Invoke, lässt deinen neuen Thread 2 Sekunden schlafen und schließt dann die Form wieder.

Da bräuchte ich dann ein bischen Hilfe

Und warum nicht gleich WPF?

Habe ich mir bisher nicht angeschaut. Wo liegt der Vorteil bei WPF?

 

[dominic.e]

wegen wpf, schau dir mal das MVC-Prinzip an (Model-View-Controller).

 

[Darlis]

Für Forms ist eine Lösung anscheinend nicht so einfach. Viele Beispiele verwenden dazu DllImport und Handles. Mit WPF geht das ganze viel eleganter.

Lern WPF, Forms wird aussterben.

 

[ML89]

Ok. Habe eben testweise mal ein neues WPF-Projekt auf gemacht. Sehe ich das richtig, dass ich ein Hauptprogramm (App) habe, und eine Form (MainWindow)? Das XAML war doch ser verwirrend

Laufen WPF-Anwendungen auch auf älteren Systemen?

 

[Darlis]

JA, bei WPF kommt XAML als neue Sprache hinzu. Der Editor nimmt dir aber am Anfang viel ab.

WPF benötigt mindestens .Net Framework 3.5, läuft also auch noch mit XP. In den Projekteigenschaften kannst du das Ziel-Framework einstellen. Gehe aber nur so niedrig wie unbedingt nötig, sonst fehlen dir u.U. einige Features. Es kann sogar auf Linux laufen, Erfahrungen habe ich damit aber nicht.

 

[Phoenixwiger]

@Darlis: Bist ein überzeugter WPF-Fan, aber WinForms hat auch nach wie vor viele Anhängern, daher haben WPF und WinForms schon seine Vor- und Nachteile und daher wurde Dein Satz schon im 2010 gesagt. Heute wird beides gerne verwendet, also lass es mit dem Satz.
Ich finde persönlich WPF total übertrieben, sie für kleine Projekte einzusetzen, da ist WinForms einfacher und besser sein als WPF.
Bedenke auch, dass viele Entwicklern dementsprechend mehr Aufwand betreiben muss, um WPF zu verstehen, denn es besteht nicht mehr aus nur GUI und Eigenschaften, sondern XAML, GUI, Eigenschaften usw.

 

[ML89]

Jetzt weiß ich auch warum viele der neuen Programme so scheiße aussehen. Ich habe zwei ListBoxen gesetzt und 100 Maße. Und jedes Mal wenn ich nur die ListBox ziehen will, setzt der mir ein neues Maß. Ist ja nett, dass Microsft da was am Editor gemacht hat, aber praxistauglich ist anders.

Also WPF ist definitiv keine Alternative. Der Editor für die Form ist ja erbärmlich. Da bin ich ja Stunden dran, nur damit die Steuerelemente an der richtigen Stelle sind.

 

[Darlis]

Klar, WinForms ist nicht "tot", aber wenn man schon anfängt einen neue Sprache zu lernen, warum dann nicht das, was gerade aktuell ist? Wenn er mit Forms anfängt und später auf WPF umsteigt, kann er die Hälfte wieder vergessen.

Ich weiß nicht, was du mit "Maß" meinst, aber verwende möglichst keine fixen Positionen und Größen. Daher sehen die "neuen Programme" auch so toll aus, da Anfänger einfach nur Ihre Controls auf das Window klatschen. Hauptsache es läuft.

Programmiren lernt man nicht in einem Tag (Controls auf eine Form ziehen ist nicht Programmieren), vor allem nicht wie man guten Code schreibt. Das braucht Zeit, Übung, ein gutes Buch/Tutorials und viel Übung.

 

[ML89]

Ich wollte einfach nur zwei ListBox machen und dann da mal ein bisschen mit Spielen. Aber dazu kommt es nichtmal.

Also ich bin ja auch der Meinung, dass man immer das Aktuelle erlernen sollte. Das macht aber nur Sinn, wenn das Aktuelle auch funktioniert. WPF tut es bei mir definitiv nicht. Wie soll ich ein Programm erstellen, wenn ich nicht einmal die Form dafür sauber hinbekomme?

Ich bleibe bis auf Weiteres bei Windows Forms.
Es hat weniger als eine Minute gebraucht die Form zu erstellen. In WPF ist mir das leider so unmöglich.

 

[Kassenwart]

Das macht aber nur Sinn, wenn das Aktuelle auch funktioniert. WPF tut es bei mir definitiv nicht.

WPF funktioniert hervorragend, wenn man das Konzept dahinter versteht.

Nein der Designer ist nicht dafür da seine Oberfläche damit zu erstellen. Wenn man Steuerelemente hin und herschieben will dann sollte man besser weiterhin bei WinForms bleiben.

Im Grunde entwerfe ich meine Anwendungen in WPF wie Webseiten in HTML. In XAML beschreibe ich die Struktur wie in HTML und über Styles steuere ich das Aussehen wie mit CSS. Einfacher geht es nicht.

WPF erfordert aber nun mal Einarbeitung, das ist nichts was man eben an einem Tag nur durch rumprobieren lernt.

 

[max_1234]

Mit Forms klappt das problemlos
Du musst nur etwas tricksen, hast dafür aber die Kontrolle über alles.

Hauptform -> neuer Thread (mit Methode, die die neue Form läd) -> In neuer Form einen weiteren neuen Thread erstellen, welcher 2 Sekunden schläft, dann close oder hide oder fadeout - whatever.

D.h. du hast 3 Threads, 2 davon selbst implementiert (1 GUI Thread - automatisch da; 2 Hilfs-Threads - einer zum Starten der zweiten Form, einer zum Warten bis sie sich schließen soll, damit der GUI Thread die Forms nicht blockiert).

Verstanden?

mfg,
Max

 

[trialgod]

Also ich bin ja auch der Meinung, dass man immer das Aktuelle erlernen sollte. Das macht aber nur Sinn, wenn das Aktuelle auch funktioniert. WPF tut es bei mir definitiv nicht.

Über so viel Ingoranz kann ich mittlerweile nur noch Schmunzeln.

Es ist aber wie es ist: Es ist deine Entscheidung ob du Windows Forms oder WPF machst. Nur eine Anmerkung noch: 4k kommt ins Rollen. Und es rollt mittlerweile ziemlich stark. Ich wünsche dir dann viel Spaß mit Forms.

Und warum WPF nun für kleine Programme "zu viel" sein soll muss mir mal einer erklären.

 

[dominic.e]

Sagen wir es mal so, um C# zu lernen (die Logik) kann man ruhig erstmal Konsole/WinForms nehmen, aber sobald man etwas größere Projekte starten will, oder eine richtige Anwendung schreiben will, würde ich auch dazu raten sich in WPF und MVC einzulesen. WPF macht nämlich auch nur dann wirklich sinn, wenn man MVC richtig verstanden hat
WPF ist wirklich eine feine Sache

 

[trialgod]

Meinst du nicht MVVM?

 

[dominic.e]

Aus Wikipedia zitiert: "Model View ViewModel (MVVM) ist eine Variante des Model View Controller-Musters (MVC) zur Trennung von Darstellung und Logik der Benutzerschnittstelle (UI)."

Ich kenn/kannte jetzt nur MVC, aber wenn der TE sich WPF anschauen will, dann soll er sich eben in MVVM einlesen Mir ging es ja nur um das Prinzip, dass man alles schön sauber trennen soll.

 

[trialgod]

Der Vorteil ist ja vorallem das DataBinding.

Ich gebe zu ich habe noch nie wirklich mit WinForms gearbeitet. Ich kenne aber ASP.NET WebForms und das ist ja daran angelehnt. Und das WPF DataBinding ist einfach extrem praktisch, wenn man verstanden hat, wie man es benutzt.

Was bei WPF komisch ist: ich scheine immer der erste mit m.M.n. Common Problems zu sein. Aber ich habe auch nie wirklich an Desktopoberflächen gearbeitet. Als Webentwicklung ist man aber mit der Trennung Struktur <-> Style <-> Logik gut vertraut.

 

[ML89]

Zurück zum eigentlichen Problem:

In einer WPF-Anwenundung habe ich ein zweites Fenster (Window) angelegt. In dieses Window habe ich eine asynchrone Funktion geschrieben, nach deren Ablauf dieses Fenster schließen soll:

this.Close();

Das Ganze funktioniert natürlich auch mit den Windows Forms. Also kein neuer Thread, kein Application.Run, einfach nur

Form.Show();

Das Problem: Ein parallel geöffneter FolderBrowserDialog wird ebenfalls geschlossen

 

[Darlis]

Es hat weniger als eine Minute gebraucht die Form zu erstellen. In WPF ist mir das leider so unmöglich.

Ich verstehe nicht, wie du diesen Dialog zustande gebracht hast. Bei mir rastet alles sauber ein. Welche Version von VS benutzt du?

Das Problem: Ein parallel geöffneter FolderBrowserDialog wird ebenfalls geschlossen

Ohne Code ist das unmöglich nachzuvollziehen. Hast du vielleicht dem Dialog die Form als Parent mitgegeben?