Laden...

STAThreadAttribute beim ScrollViewer

Erstellt von joe123 vor 2 Jahren Letzter Beitrag vor 2 Jahren 374 Views
J
joe123 Themenstarter:in
3 Beiträge seit 2021
vor 2 Jahren
STAThreadAttribute beim ScrollViewer

Guten Abend,

ich versuche eine Java Anwendung in Windows Forms zu übertragen. Leider bin ich bei den Oberflächenübertragungen sehr schlecht.
Bei dem Versuch eine JScrollPane abzubilden, bin ich auf ScrollView gestoßen. Dieses löst beim Initialisieren immer eine Exception aus. (this.scrollPane= new ScrollViewer())
"System.InvalidOperationException: "Beim aufrufenden Thread muss es sich um einen STA-Thread handeln, da dies für viele Komponenten der Benutzeroberfläche erforderlich ist."

Ich verstehe leider gar nicht, wie ich dieses Problem beheben kann, bzw. wo es herkommt. Kann mir hier jemand helfen? Ist vielleicht die gewählte Klasse nicht optimal?

Vielen lieben Dank
Joe

2.078 Beiträge seit 2012
vor 2 Jahren

Einfach mal nach "STAThreadAttribute" suchen ...

STAThreadAttribute Class
CA2232: Windows Forms-Einstiegspunkte mit STAThread markieren. - Visual Studio

Apply this attribute to the entry point method (the Main() method in C# and Visual Basic). It has no effect on other methods.

using System; 
using  System.Windows.Forms;

namespace UsageLibrary
{
    public class MyForm: Form
    {
        public MyForm()
        {
            this.Text = "Hello World!";
        }
        
        // Satisfies rule: MarkWindowsFormsEntryPointsWithStaThread.
        [STAThread]
        public static void Main()
        {
            MyForm aform = new MyForm();
            Application.Run(aform);
        }
    }
}
J
joe123 Themenstarter:in
3 Beiträge seit 2021
vor 2 Jahren

Hallo,

vielen Dank das funktioniert.
Aber auch nach dem ich einige Suchergebnisse durchgelesen habe verstehe ich nicht wieso einige GUI-Elemente diese Anweisung benötigen und andere nicht. Hängt dies daran, dass das Element eine Eigenschaft hat die Oberfläche zu ändern ohne ein Event? Also z.B. das Scrollen?

Danke
Joe

C
55 Beiträge seit 2020
vor 2 Jahren

Ich würde dir eher zu WPF mit MVVM raten, da kommst du gar nicht erst in die Situation GUI Elemente im Code zu erzeugen, da die Ganze GUI mit XAML erzeugt/erstellt wird.

4.931 Beiträge seit 2008
vor 2 Jahren

Hallo Joe,

bei Windows Forms gibt es keine ScrollViewer-Klasse. Hast du evtl. die WPF-Klasse ScrollViewer eingebunden?

Für Windows Forms kannst du ein Panel (oder jede andere von ScrollableControl abgeleitete Klasse) benutzen und dessen Eigenschaft AutoScroll auf true setzen.

J
joe123 Themenstarter:in
3 Beiträge seit 2021
vor 2 Jahren

Hi,

dankeschön, ja ich glaube da habe ich das mit genutzt ohne es zu merken.

Vermutlich stimmt es, dass es besser wäre WPF zu nutzen, ich muss gestehen, ich dachte Java nach Forms zu konvertieren wäre der schnellere Weg, da mehr Elemente sich zu ähneln scheinen.

Viele Grüße
Joe

F
10.010 Beiträge seit 2004
vor 2 Jahren

Je ähnlicher es scheint, umso schwieriger wird es für dich, da die die Fehler bei der Umsetzung nicht auf den ersten Blick ersichtlich sind.
Auch verleitet das dann dafür ein Java Programm zu erstellen und kein C# Programm ( Namingconvention, Pattern usw. ).

2.078 Beiträge seit 2012
vor 2 Jahren

Generell bin ich mir nicht sicher, ob es so klug ist, ein Java-Programm 1-zu-1 nach .NET zu portieren.
So ähnlich, wie es auf den ersten Blick scheint, sind die Sprachen sich gar nicht, es gibt einige Details (z.B. Generics), wo sich die Sprachen sehr unterscheiden.
Im schlimmsten Fall baust Du dein .NET-Programm auf einer Annahme auf, die bei .NET einfach nicht zutrifft und hängst dann in der Luft und musst Workarounds finden, die sich früher oder später rächen werden. Oder umgekehrt, Du übersiehst ein Feature von .NET, was dir für ein Feature eine viel bessere Lösung bieten könnte.

Bei Projekten, die auch etwas länger "leben" sollen/müssen, kann es klüger sein, das Projekt vom Reißbrett neu zu entwerfen und nur gelegentlich beim Original zu spicken. Das setzt aber auch entsprechende Erfahrung mit C# und natürlich umfangreiche Kentnisse zu den Funktionen des Programms voraus. Traurigerweise ist Letzteres das häufigere Problem, zumindest nach meiner Erfahrung.