Suchergebnisse

Die Frage ist oft: Brauchst du tatsaechlich Commands, oder bindest du Eigenschaften. Vorselektion, Selektion, Durchsuchen - das klingt alles mehr nach Eigenschaften-Binding (koennte sich mit mehr Kontext natuerlich aendern). Nur das Ausloesen von einer konkreten Aktion anschliessend wuerde meines Erachtens dann den eigentlichen Command erfordern. Und ja, das Klicken eines Eintrages, _um_ ihn zu selektieren, hat schon Command Charakter. Aber es ist streng genommen dann die "SelektierterKunde" Eig…

Vielen Dank fuer die vielen Antworten - ich habe alle aufmerksam gelesen, und werde mir Gedanken machen! Zwei Dinge schon jetzt: An der Dokumentation arbeiten wir, und das Thema Deutsche Uebersetzung kann ich SEHR gut nachvollziehen: In der Zeit, als ich noch fuer MS Press in Deutschland Fachbuecher schrieb und uebersetzte, habe ich erst versucht, mich gegen die Terminologievorgaben zu stemmen (Was zum Teufel soll eine 'Schaltflaeche' ueberhaupt sein? Und wer kann mir mal bitte seine Briefmarken…

ausgelagert aus Projektplanung DataSet/DataTable typisiert ~VaporiZed Ich habe mal ne generelle Frage: Was hindert euch daran, modernere Versionen oder Libraries zu verwenden, also hier in diesem Fall beispielsweise EntityFramework, EFCore und .NET? Wuerde mich sehr interessieren, was wir von Microsoft-Seite tun muessten, um die Adaption interessanter oder einfacher zu machen. (Und ja, ich weiss, dass es keinen Microsoft-nativen EFCore-Support fuer VB gibt, aber es gibt das hier: github.com/efco…

Es waere super-hilfreich, wenn du dein Anwendungsbeispiel als Issue im WinForms Repo melden wuerdest! Ich sehe in Sachen "Unicode und moderne Fonts" einen Alptraum auf uns zukommen, deswegen pushe ich intern zur Adaption fuer Direct2D/DirectWrite in WinForms fuer zumindest einige performance- oder A11Y-kritische Issues. Je mehr Feedback aus dieser Richtung von der Community kommt, desto besser!

Das Problem ist Folgendes: Visual Studio 2019 ist 32-Bit, Visual Studio 2022 ist 64-Bit. Das bedeutet, dass der WinForms Designer natuerlich auch in der Bitness des Host-Prozesses laeuft, also je nach Version 32-Bit oder 64-Bit. Wenn ein Projekt mit "Any" kompiliert werden kann, startet der Designer zur Entwurfszeit die entsprechend verwendeten Controls und deren Designer (und die entsprechenden "darunterliegenden" Komponenten) mit der Bitness, die der Hostprozess vorgibt. Beim Profil "Any" gehe…

Zitat von VaporiZed: „Das Problem aus einem meiner Vorposts wurde dank @loeffel nun als Fehler eingestuft. “ Fix ist unterwegs - die Community kuemmert sich drum! Danke fuer deine Hilfe! github.com/dotnet/winforms/issues/10904 Und ja, Sprachangabe bei Fehlern ist immer eine gute Idee! Ihr koennt auch immer gerne Designer- und Runtime Issues selber direkt in GitHub erfassen - das erreicht uns am schnellsten. Falls ihr euch im Englischen nicht ausreichend trittsicher fuehlt, Deepl.com macht in der…

Zitat von oobdoo: „ Was mir als Vorschlag in den Kopf gekommen ist, ist eine Art Anti-Breakpoint. Den setzt man in die Function oder Sub die garantiert funktioniert. Dann könnte man sich mit F8 von einer Zeile zur nächsten Durchdrücken, ohne das der Debugger in eine Function/Sub mit Anti-Breakpoint reinspringt.“ Sollte das mit DebuggerStepThroughAttribute nicht schon funktionieren?

Ja, danke fuer den Hinweis. Ich habe unser Test-Team gebeten, ein Issue im WinForms Repo zu erstellen. Es wird vermutlich nicht fuer einen sofortigen Fix reichen, aber ich wuerde es schon als Bug ansehen. BTW: Die WinForms-Runtime ist Open Source. Ihr koennt jederzeit direkt im GitHub Repo einen Bug melden. Oder noch besser (fuer die, die sich das zutrauen): Ihr koennt auch jederzeit im WinForms Repo einen PR zum Fixen eines Bugs einreichen! LG aus Redmond, Klaus

Kannst du die Fehler mal posten? Mit dem Upgrade Assistent sollte es dann problemlos klappen, wenn du keine Third-Party-Controls verwendest. Solltest du 3rd-Party-Controls verwenden, kommst es darauf an, ob der Hersteller eine entsprechende Version fuer .NET 6-8+ zur Verfuegung stellt, da die Control-Designer der Controls des Herstellers bei einer komplexeren Designer-Benutzeroberflaeche nicht mit dem .NET Framework Designer kompatibel sind. (Das gilt natuerlich auch fuer selbstgeschriebene Steu…

40.000 Zeilen Code in InitializeComponent sind schon vergleichsweise viel. Man sollte drueber nachdenken, ob sich nicht bestimmte Steuerlement-Gruppen in UserControls bilden lassen, sodass man hier auch die Dateien pflegeleichter machen kann, indem man die Form-Definitionen ueber mehrere Dateien verteilt. Gerade der .NET Designer (.NET 5+) ist streckenweise langsamer in der Verarbeitung als der .NET Framework (In-Proc) Designer, da der gesamte Code dem .NET-Prozess zum Serialisieren und Deserial…

Hey, sorry, dass es etwas laenger gedauert hat. Ich denke momentan vorsichtig, dass das Problem nichts mit dem WinForms Designer zu tun hat. Unter .NET und im Gegensatz zu .NET Framework generiert das DataSet-Generator-Tool eine Namespace-Anweisung, die es nicht generieren duerfte, bzw. es koennte sie generieren, wenn es dem Namespace-Namen ein `Global.` voranstellen wuerde. Und das ist das eigentliche Problem. Denn wenn deine Anwendung "DsDemo" heisst, dann moechtest du wahrscheinlich, dass sic…

Zitat: „Ist eigentlich auch geplant, dass eine DGVButtonCell eine Command-Property bekommt?“ Jetzt ja! Good catch, schaue ich mir an! Wenn ihr weitere Ideen in Sachen Data Binding habt, klaus.loeffelmann at microsoft dot com oder Suggestion im WinForms GitHub Repo! Zum Fehler: In 17.9 haben wir ein grosses Update in Sachen CodeGen und VB. Ob dieses Problem da schon mit dabei ist, schaue ich mir nochmal an - falls nicht, versuche ich es den Bar fuer 17.10. zu machen. - Klaus

Zitat von Amro: „Also ich finde das komisch. Man entwicklt erst eine neue Technik(WPF) um das Databinding und so möglich zu machen,weil die alte sich nicht eignete. Jetzt gehts wieder zurück und man versucht das Neue in die alte Technologie rein zu Hämmern. Jetzt stellt sich die frage ob man das nicht gleich richtig macht und sich die Zeit erspart bis man merkt das es mit WPF doch besser ist . “ Das sieht auf den ersten Blick tatächlich so aus, das ist richtig. Du darfst aber Folgendes nicht ver…

Zitat von VaporiZed: „Das wär aber eine Frage @loeffel.“ Es gibt eine Regression im Build System, so wie es ausschaut. Hat nichts direkt mit WinForms zu tun - die genauen Ursachen recherchieren wir noch. Jedenfalls sollte zusaetzliches Einfuegen von folgendem fuer Abhilfe sorgen: <GenerateRequiresPreviewFeaturesAttribute>true</GenerateRequiresPreviewFeaturesAttribute> In .NET 8 ist es GA (general available), da braucht es diese Attribute dann nicht mehr. HTH, Gruss aus Redmond, Klaus

Ich lese aktiv mit seit heute, ja! Ist das bei euch ein VB-only Problem, oder ist C# ebenfalls betroffen? Wenn es bis 17.5.3 funktioniert hat, dann wird es eine Regression sein, die wir bei der Umstellung der Codegenerierung von CodeModel auf Roslyn verursacht haben. Es gibt gerade bei VB noch einige andere Dinge, die wir fuer 17.9 Preview 3 angehen. Werde mir es genauer anschauen und mich dann melden.

In WinForms in .NET haben wir den aktuellen FolderDialog implementiert. Ich meine, dass war sogar einer der ersten Community PRs im .NET WinForms Repo. Im letzten .NET Conf Talk zu WinForms, haben wir die Neuigkeiten in .NET vs. .NET Framework auch nochmals zusammengefasst: youtube.com/watch?v=N1weyWS_pL0&t=11s

Das hat was mit Generics und dem New() Constraint zu tun (sorry, ich schreibe hier jetzt Denglish, weil ich die deutschen Begriffe nicht mehr kenne). Grundsaetlich hast du Recht, dass die Access Modifier mit Internal/Internal und Internal/Public aufs Gleiche hinauslaufen. Der einzige Unterschied (von Reflection mal abgesehen) ist, wenn du eine generischen Typ definierst, der den New Constraint vorschreibt. _Dann_ spielt der Unterschied internal/public eine Rolle. Beim VB AppFramework ist es so, …

Zitat: „Ist ne coole Idee, dass man es vom My-Namespace geschenkt bekommt, aber konzeptionell empfinde ich dies eher als inkorrekt“ Ihr muesst natuerlich VB im historischen Kontext betrachten. Auch wenn es viele inkompatibilitaeten zu VB6 gab, haben wir damals schon darauf geachtet, dass moeglichst viel gleich blieb (oder man moeglichst wenig aendern musste, obschon das .NET Framework viele Aenderungen einfach hat erforderlich werden lassen). Und Default Form Instances gehoerten zu VB6, und desw…

Ich persoenlich faende individuelle Label fuer die verschiedenen .NET Versionen besser - auch fuer uns hier drueben bei MS, weil ich zumindest desoefteren auch durch die Foren browse um zu sehen, ob irgendetwas mit WinForms oder VB hakt. Und dann ist es natuerlich wesentlich schneller, und man uebersieht auch nicht so schnell, wenn man gezielt per Knopfdruck nach .NET 7 und .NET 8 selektieren kann. Im uebrigen arbeiten wir aktuell an .NET 9 - nur so nebenbei erwaehnt. Noch besser waere es, wenn …

Aus gegebenem Anlass: Meine Kollegin vom Project System und ich (WinForms) haben vor kurzem in einem .NET Blog Post die Neuigkeiten im VB Application Framework fuer .NET vorgestellt und in dem Zusammenhang auch einen Blick "unter die Motorhaube" geworfen und erklaert, wieso das VB App Framework oftmals ein wenig wie eine Black Box wirkt, es aber im Grunde genommen gar nicht ist. Ja, der Post ist auf Englisch, aber ich denke dass die einschlaegigen Uebersetzungstools inzwischen einen guten Job ma…

Oh sorry! Rod, natuerlich! Achte ich das naechste Mal besser drauf! :-S

Hallo alle, ich habe gerade versuchsweise ein neues VB Projekt mit VS 2022 und .NET 7 erstellt, und konnte es problemlos erstellen, bearbeiten und auch starten. Um so mehr bin ich jetzt daran interessiert, wo es bei euch hakt. Ich muesste wissen: a) Verwendet ihr die deutsche oder englische Version von VS? b) Welche Version verwendet ihr genau (Help/Hilfe -- About Visual Studio/Ueber Visual Studio). Zum Hintergrund vom Start-Form: Die Zeile Me.MainForm = Form1 ist korrekt. Da sich der code im My…

Verwendest du spezielle Dritt-Hersteller Steuerelemente (oder aeltere COM-Komponenten, die nur 32-Bittig funktionieren)? Dann wird das die Ursache sein. Ein Ansatz koennte sein, deine Bitness auf "Any" zu stellen fuer das gesamte Projekt. Schau mal, ob du den Designer dann oeffnen kannst. Ansonsten muestest du zur 17.8 Version warten. Wir (WinForms Team bei Microsoft) arbeiten an einem Out-Of-Process Designer fuer .NET Framework, der diese Probleme loesen sollte. Blog Post zum Thema ist in der M…

Hey Ron, [ Wenn du in der Lage bist, das NuGet Package System.Memory zu verwenden (war fuer .NET Framework, nicht? Fuer .NET [Core] brauchst du das nicht), kannst du das mit Span<T> oder Memory<T> loesen. Dabei gibt es die Moeglichkeit, deine Datenquelle in die "Bitness" zu casten, die du brauchst: C#-Quellcode (30 Zeilen) Probier mal aus, ob das funktioniert (zusammenkopiert, manuell editiert, nie getestet... ) Die Performance-Unterschiede in .NET Framework und .NET koennen in diesen Bereichen …

Schaut mal hier, das zeigt das Anwendungsframework hinter den Kulissen, und ist in diesem Zusammenhang vielleicht ganz hilfreich: https://devblogs.microsoft.com/dotnet/update-to-winforms-vb-appframework/ Wir haben hier in .NET Core einige neue Events eingefuehrt, insbesondere um HighDPI-Darstellungen aller Forms vor dem eigentlichen Appstart einzustellen. Darueberhinaus: Jedes Form benoetigt eine innere Nachrichtenverarbeitungswarteschleife (Windows Message Loop), in dem auf Windows Nachrichten …

Yep, so sollte es gehen! Gut zu wissen, dass es jetzt geht! Wie gesagt: Wir arbeiten fuer 17.6 und folgenden an weiteren Formatierungs- und Performanceverbesserungen. Falls euch noch was auffaellt, email an mich bitte - das ist wirklich hilfreich, weil es oft edge cases sind, ueber die wir im testing nicht gestolpert sind.

Oh ja sorry. 17.5.*4* sollte den Fix haben. ".4" bedeutet 4. service release, ich meine wir haetten es im 3. geshippt. 17.6 ist die aktuelle oeffentliche Visual Studio Preview. (Intern sind wir bereits am darauf folgenden Release).

Wir haben fuer 17.6 (und geserviced mit dem letzten Service Pack fuer 17.5) einen Bug gefixt, bei dem die Handles clause Definitionen verloren gingen konnten (nicht immer - in Abhaengigkeit von bestimmten Aenderungen die zuvor gemacht wurden), wenn man ohne zu speichern beispielsweise zu einem anderen Formular gewechselt und wieder zurueckgewechselt ist, oder wenn man ohne zuvor zu speichern die App mit attachtem Desbugger gestartet hat. Schau mal, ob du per Visual Studio Installer (einfach dana…

Geh einmal bitte manuell in den Designer-Code und entferne die ueberfluessigen Klammern um alle CType-Ausdruecke. Speichere ab, und teste ob du a) Das Form wieder oeffnen kannst b) Das Speichern anschliessend wie gewohnt funktioniert. Fuer riesige Formulare lassen sich mit Suchen/Ersetzen und diesen regulaeren Ausdruecken der Designer-Code in "einem Rutsch" reparieren: Search for: \((\bCType)\((.*)\)\) Replace by: $1($2) (Bitte dazu "Regulaere Ausdruecke verwenden" anklicken)

Wir haben eine Reihe von Improvements in diesem Zusammenhang auch ins letzten Service Pack von 17.5 zurueckgemergt - die sollten damit in 17.5.3 auch vorhanden sein. Es wird - ich hab's an anderer Stelle schon erwaehnt - aber noch Improvements gerade im VB Bereich geben. Sollten euch noch Dinge in diesem Kontext auffallen, bitte im WinForms Repo per neuem Bug Report melden (falls ihr euch in Englisch nicht ausreichend trittsicher fuehlt, schreibt zur Not in Deutsch, ich wuerde dann uebersetzen).…