Designer-Code in Programm-Code integrieren

[Nihilist]

Hallo,

ich beschäftige mich erst seit sehr kurzer Zeit mit VB.Net in Visual Studio 2010. Mein Problem ist folgendes:

Wenn ich ein Form-Objekt erstelle, speichert VS den Designer-Code in eine externe Datei. Ich habe bisher in VS noch keine Voreinstellung gefunden die den Designer-Code in den Programm-Code integriert. Dies ist bei den meisten Samples der Fall und erleichtert "Thread-übergreifende Zugriffe" enorm. Kann mir da jemand helfen?

Vielen Dank im voraus

[gfoidl]

Hallo,

der Compiler integriert den Desinger-Code in den "Programm-Code". Es ist auch sinnvoll dass die Trennung in 2 Dateien stattfindet (empfindet zumindest der Rest der Programmierer-Welt \ {du}). Und thread-übergreifende Vorgänge haben damit gar nix zu tun. Wenn du Invoke/BeginInvoke abzielst dann hat das im Code der Controls erzeugt/positioniert auch nix verloren.


mfG Gü

[Ralf Jansen]

Wenn ich ein Form-Objekt erstelle, speichert VS den Designer-Code in eine externe Date

Nein. Die Designer.VB Datei gehört genauso zu deinem Projekt wie die eigentliche VB Datei. Partielle Klassen die man auf mehrere Dateien verteilen kann sind ein rein strukturierendes Feature zur Designzeit. Der erstellte Bytecode unterscheidet sich nicht egal ob alles in einer partiellen Klasse steckt oder in mehreren. Insofern kann das auch keinen Einfluss auf das Laufzeitverhalten haben.

Vielleicht solltest du das mit dem "Thread-übergreifende Zugriff" mal erklären wo du da ein Problem siehst.

[Nihilist]

Vielleicht habe ich mich unverständlich ausgedrückt. Bin halt noch sehr frisch in dem Bereich und mit fachspezifischen Ausdrücken nicht bewandert.

Wenn ich z.B. aus einem Thread heraus auf eine TextBox zugreifen will, wird normalerweise eine Ausnahme ausgelöst die sinngemäß sagt, dass auf ein Objekt das außerhalb des Threads erstellt wurde als der aufrufende Thread, nicht möglich ist.

Das Problem ließe sich zwar mit Invoke lösen, wobei erst ermittelt werden muss, ob ein Invoke überhaupt notwendig ist. Das kostet Zeit und Umstände.

Die bessere Lösung ist sicher die Initialisierung innerhalb des Threads in dem auch der aufrufende Thread erstellt wird. Das heißt:


Class Programm

Public Sub New()
MyBase.New()
I nitializeComponent()
End Sub

Private Sub InitializeComponent()
…
…
…
End Sub

End Class

Diese Initialisierung geschieht nicht wenn ich ein Projekt in VS erstelle. Meine Frage ging dahin, wie man sicherstellen kann, dass VS auf obige Weise initialisiert.

[gfoidl]

Hallo,

eine WinForms-Anwendung darf nur eine GUI-Thread haben* und auch nur in diesem einen dürfen die Controls erstellt werden. Das ist von .net (nicht von VS) sichergestellt - solange du nciht darin rumwerkst und ein anderes Verhalten aufzwingen probierst.

Invoke/BeginInvoke kostet keine Zeit im Vergleich zu deinem Versuch das anders (um nicht zu sagen falsch) zu machen.


mfG Gü

* das stimmt 0,999 der Fälle. Der Rest ist wenn neue Nachrichtenschleifen erstellt werden, aber das ist selten.

[Ralf Jansen]

Die bessere Lösung ist sicher die Initialisierung innerhalb des Threads in dem auch der aufrufende Thread erstellt wird. Das heißt:

Du musst schon die ganze Form in dem anderen Thread erzeugen. Dann ist aber weiterhin egal in welcher partiellen Klasse welcher Teil implementiert ist. Ich würde dir die Invoke Methode die du nicht möchtest trotzdem empfehlen. Den notwendigen Code dafür kann man sicherlich in irgendeiner Extension Methods oder ähnliches verstecken.

Die bessere Lösung ist sicher die Initialisierung innerhalb des Threads in dem auch der aufrufende Thread erstellt wird

Nein. Die beste Lösung ist Logik von UI soweit zu trennen das ein Crossthread Call in die UI gar nicht nötig ist

@Gü : Du musst keine neue MessageLoop im anderen Thread erzeugen. Zumindest nicht um die CrossThread Calls zu verhindern. Aber man muss sich natürlich bewusst sein das die UI's in beiden Threads durch die gleiche MessageLoop gehen und sich dann doch gegenseitig blockieren können. Aber belassen wir das bei theoretischen Überlegungen besser ist definitiv nur einen UI Thread zu haben.