In Win11 ist allgemein das Window-Verhalten an manchen Stellen durch die neue Technik anders.
Musst wahrscheinlich wirklich Zeit reinstecken Zeugs auszuprobieren.
Zu manchen Dingen in Win11 wurden auch schon Bugs gemeldet, zB dass der Hibernate Event über Win32 nicht mehr gefeuert wird.
Da musst Du auf andere Komponenten zurück greifen.
Ein Entwicklungsframework bietet keine fertigen Logik-Windows, weder in .NET noch in Java und Co, sondern Bausteine, dass Du sowas machst / machen kannst.
Wie gerade geschrieben: wähl das richtige Projekt-Template aus.
Is wirklich nich so schwer.
Die SDKs installiert man als Dev i.d.R. auch über den Visual Studio Installer und nicht mit nem externen Installer.
=> Individual Components => .NET -> .NET Framework xx SDK
Dann kommen auch die Templates mit.
.NET Framework (bis 4.8) und .NET 5 sind völlig verschiedene Projekt-Templates, bei denen Du nie untereinander wechseln kannst.
Du musst die Framework Templates bei der Erstellung auswählen.
Alle alten .NET Framework-Projekte haben in den jeweiligen Titeln auch .NET Framework aufgeführt, sodass man es erkennt; zB Console Project (.NET Framework)
Es gibt eine alte Welt (.NET Framework) und eine neue Welt (.NET). Du willst die alte Welt, hast aber die neuen Templates verwendet.
Wenn Du nur zwischen .NET 3.1 (3.7 gibts nicht) und .NET 5 wählen kannst zeigt, dass Du die neuen .NET Templates (ehemals .NET Core) verwendest (kein .NET Framework).
Warum macht MS die gleiche Klasse in verschiedene Module? Aber sei es drum.
Das hat nichts mit Microsoft zutun, sondern wie Software Architektur funktioniert.
Und hier kann es in einer modularen Denkweise durchaus valide sein, dass man entsprechende Dinge modelliert.
Dass dabei die Namen manchmal gleich sind: kommt vor.
Aber genau deswegen gibt es Namespaces, zur unabhängigen Architektur-Möglichkeit.
Daher sollte jeder Entwickler auch die Namespaces seiner Sprache (C#, Java..) im Griff haben. Organizing types in namespaces
Wow, ASPX. Fast so alt wie die Dinos ;-)
Die englische Fehlermeldung lautet
Fehler
Unable to find the requested .Net Framework Data Provider. It may not be installed.
mit der sich i.d.R. mehr auf Google finden lässt, als mit deutschen Fehlermeldungen.
Daher ist es auch eher ratsam, auf lokalisierte SDKs zu verzichten.
Damit für den Kontext (bei dieser sehr alten Anwendungsart zumindest) der Provider bekannt ist und als "installiert" gilt, musst Du ihn in der Config-Section DbProviderFactories registrieren. Abrufen einer 'DbProviderFactory' - ADO.NET
Sollte eigentlich auch in der Anleitung des Postgre Providers stehen.
Except() verwendet Equals() zur Gleichheitsbestimmung, und per default Unterscheiden sich Objekte anhand der Referenz.
Du willst aber keine Referenzen sondern Werte vergleichen, wozu Du IEquatable implementieren musst.
Aber: steht alles in der Doku inkl. Beispielen - muss man einfach lesen ;-)
Das kommt auf den Fall an. Split ist in vielen Szenarien kontraproduktiv, wenn man "ab dem ersten Treffer" etwas will. Da ist IndexOf i.d.R. die bessere Variante.
Split ist ja eher "dazwischen".
Woher hast Du es denn dann, gib ma paar Infos und lass uns nich raten :-)
Speicherzugriffsfehler in Prozessen führen i.d.R. immer zum Crash, daher muss man sie vermeiden, bevor sie auftreten.
Die Exception ist im Endeffekt ein Hinweis, dass Du womöglich einen Fehler beim Speicherzugriff hast.
Du solltest also die Ursache korrigieren, nicht die Exception.
HandleProcessCorruptedStateExceptions greift nur in NetFX Projekten. Der Prozess selbst bleibt aber "corrupt".
In .NET Core bzw. .NET 5 und höher gibts das Attribut auch; macht aber nichts. Existiert nur noch aus Kompatibilitätsgründen.
Und ich denke, Abt meint die OutOfMemoryException.
Der Abt meint mehrere Exceptions.
Alle Exceptions, die laut .NET auf einen "corrupted state" des Prozesses hinweisen, darunter AccessViolationException und OutOfMemoryException.. können nicht gefangen werden.
Welche Exception bekommst Du? Nicht alle Exceptions kann man abfangen, zB MemoryExceptions.
Bitte Fehlermeldungen im Original posten, siehe [Hinweis] Wie poste ich richtig?
Für die Kommunikation mit der Win32 arbeitet man eigentlich mit Feldern, nicht mit Eigenschaften, daher sollte es (wahrscheinlich) so aussehen:
public struct Rect
{
public int Left;
public int Top;
public int Right;
public int Bottom;
}
Was anderes sticht mir aufs erste nicht ins Auge; vor allem da es bei Dir ja wohl auch nur an den Werten liegt und Du sonst kein Fehler bekommst, oder?
Was das Maximale ist, das kann Dir keiner beantworten.
Geld ist auch nicht immer der einzige Faktor; mir persönlich kommt es da auch auf mehr an und ich zB. hab auch schon auf Geld verzichtet um andere Vorteile zu haben (vor allem Zeit, Home Office und eine positive Arbeitsumgebung).
Klar, ich würde Dir auch gern sagen: Hey, locker 5000€.
Aber das ist halt keine seriöse Antwort. Ich kenne bis heute meinen absoluten Marktwert auch nicht.
Ich wunder mich selbst wie manche Leute an Gehälter gekommen sind und ich mich frag: what the hell - aber auch Devs die deutlich unter Markt verdienen.
Es gibt da einfach keine perfekte Antwort.
Ich kenne auch Personen, die eine Anstellung angenommen haben, die weniger Geld gebracht haben als Hilfe vom Staat - einfach weil sie arbeiten wollten.
Das sind also alles sehr individuelle Entscheidungen von Dir.
Zur IDE, soll man später alle Komponenten zur Laufzeit erstellen? Wäre mir zu aufwändig. Für die Oberfläche und zur Wiederbenutzung sind doch genau solche Sachen, wie auch die Code Snippets z.B. prop Tab Tab.
In der Regel passiert das in größeren, mächtigeren Anwendungen zur Laufzeit, ja.
In Windows Form durchaus oft sogar mit eigener Positionsberechnung; in WPF mit XAML funktioniert das über Bindings etwas einfacher.
Irgendwie macht VS etwas intelligentes im Hintergrund, um die Komponente visual sichtbar zu machen, dass ich manuell nicht erkennen kann.
Ist irgendwo in den Docs beschrieben; ich finds gerade nicht:
Die Toolbox ergibt sich aus dem aktuellen Kompilat. Sprich, Du musst Deine Anwendung bauen, danach baut VS seinen Cache auf bzw. aktualisiert diesen (im .vs Ordner der Solution/Projekt).
Danach taucht das Zeug auf; egal ob das nun eine Toolbox ist oder andere Dinge in der IDE.
Man muss aber auch sagen, dass man sowas wie die Toolbox eher als Anfänger verwendet als in der professionellen, fortgeschrittenen Welt.
Da verwendet man solche IDE Hilfsmittel eher sehr selten bis gar nicht.
Zitat von jodahush
aber irgendwie muss ich wohl die "using" Geschichte noch besser verstehen.
Ganz neutrale Bewertung: ich denke, dass da allgemein die Grundlagen noch nicht sitzen ;-)
Kommt aber alles mit der Zeit, man muss nur Zeit reinstecken.
Was Du da anfängst ist ein riesen Rattenschwanz. Du wirst dutzende Edge Cases haben, die Du alle abfangen musst, wenn Du das Rad wirklich neu erfinden willst.
Konstruktoren sind generell ein Problem, weshalb es bei Entitäten hier auch die Regel gibt: leerer Konstruktor als Default ist pflicht.
ListViewEmbeddedControls ist ein ungewöhnlicher Name für einen Namespace.
Aber ist das der Namespace, in der die Deklaration bekannt gemacht werden kann, dann funktioniert das über ein using.
Geht das trotzdem nicht, dann ist die Deklaration womöglich wo anders. An dem Code hier ist aber nicht zu erkennen wo.
Das war ehrlich gesagt zu erwarten, so schnell wie Du eine "Lösung" hattest.
Warum? Man muss das Konzept verstehen, ansonsten wirst Du offensichtliche und versteckte Probleme bekommen.
Daher hab ich Dir auch die Doku dazu gepostet.
Zitat von lolcore
die methoden laufen nicht gleichzeitig.
Auch das zeigt den Verständnisfehler.
Asynchrone Programmierung und parallele Programmierung sind zwei verschiedene Konzepte - und async/await ist ein asynchrones Konzept.
Zitat von T-Virus
Du müsstest nur auf den Task von testit warten und Run ohne await laufen lassen.
Nein, das sollte man nicht tun, da ansonsten zB auch Exceptions unterdrückt werden.
Um mehrere Tasks parallel auszuführen gibt es TzB ask.WhenAll.
Naja, die Parameter stimmen halt nicht, siehe Thread Klasse (System.Threading)
Du kannst bei Dir in Deiner Zeile 123 keine Methode mit Parametern verwenden, sondern musst das Delegat bekannt geben.
Ansonsten der Hinweis, dass man asynchrone Dinge wenn immer möglich mit Tasks umsetzen sollte, nich mit Threads.
Hier ist nicht nur die Programmierung viel viel einfacher, sondern auch in der Runtime i.d.R. effizienter.
Gibt nur ganz wenig Use Cases, in denen Threads wirklich die bessere / einzige Wahl ist.
les Dir mal Deinen eigenen Beitrag durch und frag Dich dann, ob das jemand verstehen würde, der Dein Code nicht kennt - ich glaube nicht ;-)
Aber: will man sich Sachen in Anwendungen temporär merken, dann gibts dafür Variablen.
Davon abgesehen, Du weißt, dass System.Windows.Forms.Clipboard.SetText nur ein Wrapper der Betriebssystem-Funktionalität ist?
Dahingehend gibt es auch viele Bibliotheken, die das wegabstrahieren.
In einer "reinen Consolen App" geht das nicht; das geht nur über COM; i.d.R. via STAThread (Api-Docs).
Das gilt auch hier: willst Du auf das Clipboard über die Forms-Abhängigkeit zugreifen, musst Du die Konsolenanwendung als STAThread deklarieren (über die Main Methode).
In diesem Fall macht das UseWindowsForms unter der Haube.
Kannst Du evtl. auch erklären, was Dein eigentlichen Ziel ist, warum Du eine Konsolen-Anwendung mit Forms / WPF machen willst?
UseWindowsForms bzw. das Pendant UseWPF ist ein Compiler Feature und keine Referenz.
Das bedeutet, dass die Anwendung selbst Richtung WinForms/WPF ausgerichtet ist. Daher ändert sich natürlich auch der Default Output, weshalb Deine Konsole leer bleibt.
Wenn Du in einer Console App Dinge aus Forms/WPF verwenden willst, dann musst Du mit Referenzen arbeiten, i.d.R. via NuGet.
Das gilt aber nicht für die Anzeige selbst: Eine Message Box bzw. Fenster kannst Du aus einer Console App aber niemals öffnen. Eine Console App hat keinen UI Zugriff, was aber nicht an .NET liegt sondern wie Betriebssysteme funktionieren.
Ich hab irgendwie das Gefühl, dass Du insgesamt viel vermischt.
Daher bitte erste Frage beantworten, damit man versteht, was Dein eigentliches Ziel ist.
... das hab ich übrigens deshalb als potentielle Lösungs gesagt, weil ich nach der englischen Fehlermeldung gegoogelt habe und dort genau das stand ;-)