none
Fehler im Designer in VS 2022 RRS feed

  • Frage

  • Hallo,

    ich bekomme den Entwurf (Oberfläche) von meinem Main-Fenster nicht mehr auf. Der Designer zeigt beim Laden unter anderem folgenden Fehler:

    Öffne ich meine Solution in VS 2017 treten die Fehler nicht auf. Irgend etwas ist in VS 2022 wohl anders. Leider bin ich zu blöd, die Aufrufliste zu verstehen. Wo muss ich da suchen?

    Grüße Norbert


    • Bearbeitet norbert3 Sonntag, 20. Februar 2022 17:12
    Sonntag, 20. Februar 2022 17:11

Antworten

  • Hi Norbert,
    ich habe das mal getestet und keinen Weg gefunden, den Designer des Visual Studios zu "überreden", 32-Bit-Steuerelemente anzuzeigen. Für dein Problem sehe ich nur einen Lösungsweg:

    1. alle Projekte, die Oberflächenelemente beinhalten auf AnyCPU umzustellen. 

    2. alle Zugriffe auf die X86-Fremdkomponenenten in Klassen kapseln, die sich in Projekten befinden, die mit X86 kompiliert werden. In diesen Projekten dürfen sich dann keine Komponenten befinden, die der Designer des Visual Studios anzeigen soll. Per eigenem Code hinzugefügte Oberflächen-Komponenten funktionieren (in meinen Tests).

    Wenn deine Projekte bereits so konzipiert (gekapselt) sind, dann ist der Aufwand minimal. Schwierig wird es jedoch mit Spaghetti-Code.


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    • Als Antwort markiert norbert3 Mittwoch, 23. Februar 2022 18:51
    Mittwoch, 23. Februar 2022 18:31
  • Hi Norbert,
    das ist ja ein neuer Gesichtspunkt (UserControls). Damit der Designer die Oberfläche darstellen kann, müssen alle Bestandteile zur Verfügung stehen. Für UserControls bedeutet das, dass diese als fehlerfreies Kompilat (Assembly) dem Designer zur Verfügung stehen. Sobald im Projekt mit den UserControls auch nur ein Zeichen geändert wird (auch nur bei Änderungen eines Kommentars) wird vermerkt, dass Kompilat ungültig ist und der Designer kann die Assembly mit dem UserControl nicht nutzen und zeigt Fehler an. Das ist insbesondere stressig, wenn sich die UserControls in der gleichen Assembly wie die Oberfläche befinden und darin gearbeitet wird. Die UserControls werden in der Toolbox auch angezeigt, wenn die Assembly nicht mehr gültig ist.

    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    • Als Antwort markiert norbert3 Mittwoch, 23. Februar 2022 07:01
    Dienstag, 22. Februar 2022 19:14
  • Danke Peter!

    So ganz kann ich's leider nicht verstehen. Hab in der Soluition 28 Projekte und in dem Main Projekt, in welchem sich der Designer nicht öffnen lässt, befinden sich 18 Objekte. Im Windows Explorer sehe ich im Ordner des Main 83 Elemente, davon 5 Ordner mit Unterordnern. Es scheint mir jetzt sehr kompliziert, im VS das Main Projekt durch ein leeres Projekt zu ersetzen und da alles wieder per Hand hinein zu kopieren. Kannst Du versuchen, mir das noch ein bisschen näher zu erklären?

    Könnte das Problem auch am Designer liegen? Microsoft schreibt im Januar 2022:

    For the last several Visual Studio release cycles, the Windows Forms (WinForms) Team has been working hard to bring the WinForms designer for .NET applications to parity with the .NET Framework designer. As you may be aware, a new WinForms designer was needed to support .NET Core 3.1 applications, and later .NET 5+ applications. The work required a near-complete rearchitecting of the designer, as we responded to the differences between .NET and the .NET Framework based WinForms designer everyone knows and loves. The goal of this blog post is to give you some insight into the new architecture and what sorts of changes we have made. And of course, how those changes may impact you as you create custom controls and .NET WinForms applications.


    • Bearbeitet norbert3 Montag, 21. Februar 2022 10:11
    • Als Antwort markiert norbert3 Mittwoch, 23. Februar 2022 06:56
    Montag, 21. Februar 2022 10:10
  • Hi Norbert,
    ich vermute, dass dein Problem bei microsoft nicht gelöst werden wird. WinForms, VB.NET und die alten Frameworks werden sehr stiefmütterlich behandelt. In WPF mit Net.6 und C# und VB funktioniert der Designer auch mixed X86 und X64.

    Langfristig solltest du deshalb den Umstieg auf WPF angehen. Das ist relativ einfach, wenn im bisherigen Projekt durchgängig mit Trennung von Design und Programmlogik und DataBindings gearbeitet wurde. Alternativ funktioniert im VS2022 auch die Oberflächengestaltung ohne den Designer, was aber nicht so bequem sein kann. Dazu kann man den betreffenden Code einfach ins Load-Ereignis einbauen. Wenn das nicht allzu viele eigene Steuerelemente sind, dann ist der Aufwand überschaubar.


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    • Als Antwort markiert norbert3 Donnerstag, 24. Februar 2022 09:37
    Mittwoch, 23. Februar 2022 21:11

Alle Antworten

  • Hi Norbert,
    die dargestellten Fehler sind üblicherweise die Folge von Manipulationen im Dateisystem außerhalb des Visual Studios, z.B. Kopieren mit dem Dateiexplorer. Das Visual Studio kann dann nicht mehr die 3 zusammengehörenden Dateien finden (eigener Quellcode, vom Designer erzeugter Code und optional  Ressourcendatei). Einen solchen Fehler kann man beseitigen, indem man ein leeres Projekt anlegt, dann alle Dateien mit dem Dateiexplorer in das Projektverzeichnis kopiert und dann mit dem Visual Studio nur die Datei, die den eigenen Code enthält, als vorhandenes Element hinzufügt. Das Visual Studio baut dann die Projektdatei richtig zusammen.

    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Sonntag, 20. Februar 2022 19:20
  • Danke Peter!

    So ganz kann ich's leider nicht verstehen. Hab in der Soluition 28 Projekte und in dem Main Projekt, in welchem sich der Designer nicht öffnen lässt, befinden sich 18 Objekte. Im Windows Explorer sehe ich im Ordner des Main 83 Elemente, davon 5 Ordner mit Unterordnern. Es scheint mir jetzt sehr kompliziert, im VS das Main Projekt durch ein leeres Projekt zu ersetzen und da alles wieder per Hand hinein zu kopieren. Kannst Du versuchen, mir das noch ein bisschen näher zu erklären?

    Könnte das Problem auch am Designer liegen? Microsoft schreibt im Januar 2022:

    For the last several Visual Studio release cycles, the Windows Forms (WinForms) Team has been working hard to bring the WinForms designer for .NET applications to parity with the .NET Framework designer. As you may be aware, a new WinForms designer was needed to support .NET Core 3.1 applications, and later .NET 5+ applications. The work required a near-complete rearchitecting of the designer, as we responded to the differences between .NET and the .NET Framework based WinForms designer everyone knows and loves. The goal of this blog post is to give you some insight into the new architecture and what sorts of changes we have made. And of course, how those changes may impact you as you create custom controls and .NET WinForms applications.


    • Bearbeitet norbert3 Montag, 21. Februar 2022 10:11
    • Als Antwort markiert norbert3 Mittwoch, 23. Februar 2022 06:56
    Montag, 21. Februar 2022 10:10
  • Hi Norbert,
    ich weiß ja nicht, was du genau gemacht hast. Wenn du durchgängig mit dem Visual Studio gearbeitet hast und die Projekte immer aus den DevOps per TFSVC oder Git geladen hast, dürfte das nicht passieren. Mein Beitrag waren nur eigene Erfahrungen nach Kopiervorgängen über den Datei-Explorer. Der Designer nimmt deine Code-Datei und führt darin InitializeComponent aus. Und wenn da in der Projektdatei keine Designerdatei vermerkt ist oder dieses sich nicht am vermerkten Platz befindet, dann kommt besagter Fehler. Die Struktur der Projetdatei ist für das klassische Framework geringfügig anders als für das aktuelle NET.Core. Die Struktur der Projektdatei von WindowsForms Projekten unterscheidet sich von WPF Projekten.

    Lösen kann man das, indem man erst einmal die Projektdatei inspiziert und schaut, ob da alles vermerkt ist und die vermerkten Dateien auch zugreifbar sind. Und da kann es wegen Kopieren außerhalb des Visual Studios schon zu Fehlern kommen. Wenn da etwas nicht stimmt, ist es am einfachsten, die betreffenden Dateien zu löschen (vorher natürlich sichern), dann die Dateien aus der Sicherung mit dem Dateiexplorer in das betreffende Verzeichnis kopieren und mit dem Visual Studio nur die Datei mit dem eigenen Programmcode dem Projekt hinzufügen. Das Visual Studio baut dann automatisch die richtigen Bezüge in die Projektdatei zu den anderen Dateien ein, die sich natürlich mit den passenden Dateinamen im gleich Projektverzeichnis befinden müssen. Da kann man in einem separaten leeren Projekt machen oder auch im konkreten Projekt und da ggf. in den Unterordnern. Das muss man so oft wiederholen, wie es Fenster gibt, die sich nicht mit dem Designer bearbeiten lassen.


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Montag, 21. Februar 2022 15:10
  • Nochmals Danke. Mit "Projektdatei" meinst Du jetzt welche Datei? Im VS oder im Windows Explorer?

    Ich frage mich, warum der Fehler beim Öffnen der Solution mit VS22 auftritt, nicht aber wenn ich dieselbige mit VS17 öffne. Es geschieht beides im gleichen Ordner mit denselben Dateien ???

    Montag, 21. Februar 2022 16:57
  • Hi Norbert,
    in VB.NET Projekten heißt die Datei <Projektname>.vbproj
    Sie befindet sich im Ordner des Projektes.

    Die Frage, warum es Probleme gibt, kannst du dir beantworten, wenn du mal in die Projektdatei schaust und ergründest, was da fehlt. Dein dargestellter Fehler kann kommen, wenn die Projektdatei und die vorhandenen Dateien nicht passen.



    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Montag, 21. Februar 2022 18:27
  • Lieber Peter,

    dafür, dass Du so viel Geduld mit mir hast, kann ich Dir gar nicht genug danken. Ich wollte Dir in früheren Diskussionen schon öfter unterstellen, dass Du Unrecht hast. Aber zum Schluss hast Du mir immer beweisen können, dass ich Tomaten auf den Augen hatte.

    Dieses Mal neige ich aber wirklich dazu, dass Du auf der falschen Fährte bist. Ich habe stundenlang nach fehlenden Dateien gesucht, aber nix gefunden. Es muss ein Bug in VS 2022 sein. Der Fehler, dass bei manchen Forms der Designer nicht geöffnet werden kann, tritt auch bei allen früheren Versionen unserer App unter VS22 auf. Die können keinesfalls alle fehlerhaft gewesen sein. Wir haben außerdem heute eine VS22 auf einem anderen Rechner installiert und es zeigt sich das gleiche Bild. Ich habe herausgefunden, dass es wohl an meinen UserControls liegen muss. Sie werden scheinbar nicht richtig bzw. gar nicht kompiliert. Es fällt auf, dass sie zwar in der Toolbox zu sehen sind, wenn ich aber eins auf ein Form ziehen will, kommt die Meldung "Fehler beim Laden von Toolboxelement 'xyz'. Es wird aus der Toolbox entfernt." Das passiert bei allen UserControls in den unterschiedlichsten Projekten. Und alle Forms, bei denen ein UserControl im Spiel ist, kann der Designer von VS22 nicht öffnen. Kannst Du Dir das erklären?

    Viele Grüße Norbert


    • Bearbeitet norbert3 Dienstag, 22. Februar 2022 16:35
    Dienstag, 22. Februar 2022 16:34
  • Hi Norbert,
    das ist ja ein neuer Gesichtspunkt (UserControls). Damit der Designer die Oberfläche darstellen kann, müssen alle Bestandteile zur Verfügung stehen. Für UserControls bedeutet das, dass diese als fehlerfreies Kompilat (Assembly) dem Designer zur Verfügung stehen. Sobald im Projekt mit den UserControls auch nur ein Zeichen geändert wird (auch nur bei Änderungen eines Kommentars) wird vermerkt, dass Kompilat ungültig ist und der Designer kann die Assembly mit dem UserControl nicht nutzen und zeigt Fehler an. Das ist insbesondere stressig, wenn sich die UserControls in der gleichen Assembly wie die Oberfläche befinden und darin gearbeitet wird. Die UserControls werden in der Toolbox auch angezeigt, wenn die Assembly nicht mehr gültig ist.

    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    • Als Antwort markiert norbert3 Mittwoch, 23. Februar 2022 07:01
    Dienstag, 22. Februar 2022 19:14
  • Dann werden wir wohl mit VS 2019 weiterarbeiten und VS22 vom Rechner fegen. Denn so kann man nicht arbeiten. Meldet das jemand von euch bei Microsoft?

    Mittwoch, 23. Februar 2022 07:02
  • Hi Norbert,
    das Problem liegt aber auch bei Visual Studio 2019 vor. Es kann sich nur sehr unterschiedlich äußern und in deiner Umgebung mit fertig übersetzten Projekten kann es zufällig im VS 2019 funktionieren, nach einer neuen Übersetzung in VS2022 kann es dann Probleme geben. Hier mal ein konstruiertes Beispiel im VS 2019 nach einer fehlerfreien Übersetzung des Projektes:


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Mittwoch, 23. Februar 2022 08:43
  • Kann ich nicht bestätigen. In VS 2019 auf zwei Maschinen läuft alles problemlos. Alle UserControls lassen sich auf diverse Forms ziehen. Jedoch knallt es auf beiden Maschinen, wenn die sln in VS 2022 gefahren wird.

    Mittwoch, 23. Februar 2022 08:53
  • Hi Norbert,
    dein Bild im Originalposting sagt aus, dass die Assembly mit dem FormTabControl im Namensraum FormEditor nicht in einer fehlerfrei übersetzten Version dem Designer im frmHauptFenster zur Verfügung steht. Warum diese fehlerfrei übersetzte Assembly nicht zur Verfügung steht, solltest du erst einmal prüfen. Wenn diese fehlerfrei übersetzte Assembly im VS 2019 nicht zur Verfügung stehen würde, würde der gleiche Fehler erscheinen. Ursache des Unterschieds können auch unterschiedliche Einstellungen zu PLattform und/oder CPU sein.

    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Mittwoch, 23. Februar 2022 09:38
  • Danke Peter,

    das Projekt FormEditor mit der darin enthaltenen Klasse FormTabControl wird fehlerfrei gebildet. Die zugehörige Dll liegt im richtigen Verzeichnis. Dein Hinweis betr. den Einstellungen zur Plattform könnten in die richtige Richtung gehen. Im Netz habe ich mehrfach Berichte darüber gefunden.Z.B.

    vs 2022 windows form designer error with datasource

    Winforms Designer does not work for 64-bit Winforms Applications

    Windows forms designer unable to load form

    Da ist oft von der "Plattform" die Rede. Leider hab ich die englischsprachigen Ausführungen nicht vollständig verstehen können, auch nicht nach einer Übersetzung ins deutsche.


    Mittwoch, 23. Februar 2022 11:13
  • Hi Norbert,
    dein Fehler ist reproduzierbar. Deine Assemblies bauen auf unterschiedlichen Plattformen auf: frmEd510 ist festgelegt auf 32 Bit CPU und das Main-Programm ist für Any-CPU festgelegt. VS 2022 arbeitet mit dem 64-bit MSBuild, VS 2019 dagegen mit dem 32-bit MSBuild. Gelöst werden kann das Problem, indem alle Komponenten mit AnyCPU übersetzt werden.

    Übrigens hast du im VS 2019 das gleiche Problem, wenn du das Main-Programm auf X64 festlegst und deine frmEd510 auf X86:


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Mittwoch, 23. Februar 2022 14:38
  • Kann ich nicht bestätigen. In VS 2019 auf zwei Maschinen läuft alles problemlos. Alle UserControls lassen sich auf diverse Forms ziehen. Jedoch knallt es auf beiden Maschinen, wenn die sln in VS 2022 gefahren wird.

    Hallo zusammen,

    VS 2022 ist schon noch sehr fehlerbehaftet und/oder arbeitet in vielen Dingen, insbesondere Kompilierung und Debugging komplett anders als alle vorherigen Versionen.

    So habe ich bei mindestens drei ASP.NET Projekten erhebliche Probleme, zu debuggen, weil VS 2022 im Gegensatz zu allen früheren Versionen inkl. VS 2010 der Meinung ist, die App_Code*.dll doppelt oder gar dreifach erzeugen zu müssen, die Breakpoints dadurch nicht gelten oder gleich Fehler kommen, weil die deklarierten Typen nicht bzw. auch mehrfach gefunden werden (The type "xyz" exists in both "file1.dll" and "file2.dll" und andere Fehler).

    Da die Projekte teils seit 15 Jahren immer wieder erweitert werden und damit sehr umfangreich sind, konnte ich es noch nicht auf bestimmte Problemstellen runterbrechen (außer eine in VS 2022 nicht erwünschte Konstellation bzgl. einer CodeFile bzw. CodeBehind Pfadangabe) und daher leider auch noch kein Repro Projekt für den MSFT Support erzeugen.

    Fakt ist aber, dass die Projekte in VS 2010, 2012, 2015, 2017 und 2019 problemlos liefen und in 2019 auch weiterhin problemlos laufen und debuggt werden können. Nur 2022 ist schon echt stressig.

    Wie gesagt, das nur so am Rande als Info, dass es viele Leute gibt, die mit den Eigenheiten und doch noch zahlreichen Bugs in VS 2022 zu kämpfen haben.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport


    Mittwoch, 23. Februar 2022 14:46
    Moderator
  • @ Peter:

    Deine Assemblies bauen auf unterschiedlichen Plattformen auf: 
    frmEd510 ist festgelegt auf 32 Bit CPU und das Main-Programm ist für Any-CPU festgelegt. 
    VS 2022 arbeitet mit dem 64-bit MSBuild, VS 2019 dagegen mit dem 32-bit MSBuild. 
    Gelöst werden kann das Problem, indem alle Komponenten mit AnyCPU übersetzt werden.
    Genau hier habe ich eine Wissenslücke (und deshalb auch die diesbezüglichen Beiträge im Netz nicht genau verstanden). Wo siehst Du was auf welche Plattform festgelegt ist? Bei allen 28 Projekten in der sln ist als Ziel-CPU x86 eingestellt, auch beim Main (frmHauptfenster). Wir können nur so konfigurieren, weil wir einiges an Fremd-Software implemtiert/angezapft/angesteuert haben (Langzeit-Blutdruckmessungen, Ergometrie uam.), welche nur mit x86 funktionieren. Wir haben uns schon an AnyCPU versucht. Dazu müssen alle Projekte auf diese Ziel-CPU umgestellt werden. Und dann fallen wir bei der Geräteansteuerung auf die Nase.

    Mittwoch, 23. Februar 2022 17:13
  • Hi Norbert,
    ich habe das mal getestet und keinen Weg gefunden, den Designer des Visual Studios zu "überreden", 32-Bit-Steuerelemente anzuzeigen. Für dein Problem sehe ich nur einen Lösungsweg:

    1. alle Projekte, die Oberflächenelemente beinhalten auf AnyCPU umzustellen. 

    2. alle Zugriffe auf die X86-Fremdkomponenenten in Klassen kapseln, die sich in Projekten befinden, die mit X86 kompiliert werden. In diesen Projekten dürfen sich dann keine Komponenten befinden, die der Designer des Visual Studios anzeigen soll. Per eigenem Code hinzugefügte Oberflächen-Komponenten funktionieren (in meinen Tests).

    Wenn deine Projekte bereits so konzipiert (gekapselt) sind, dann ist der Aufwand minimal. Schwierig wird es jedoch mit Spaghetti-Code.


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    • Als Antwort markiert norbert3 Mittwoch, 23. Februar 2022 18:51
    Mittwoch, 23. Februar 2022 18:31
  • Lieber Peter, Deine Hilfsbereitschaft ist umwerfend! Vielen vielen Dank! Dein letzter und Stefans Beitrag bestärken mich nun doch darin, weiter mit VS19 zu arbeiten. Ich hoffe sehr, dass die Bugs in VS22 demnächst gefixt werden. Hoffentlich ist da auch die Anzeige von 32-Bit Steuerelementen dabei. Sonst wird es kritisch für uns.

    Viele Grüße Norbert

    Mittwoch, 23. Februar 2022 18:51
  • Hi Norbert,
    ich vermute, dass dein Problem bei microsoft nicht gelöst werden wird. WinForms, VB.NET und die alten Frameworks werden sehr stiefmütterlich behandelt. In WPF mit Net.6 und C# und VB funktioniert der Designer auch mixed X86 und X64.

    Langfristig solltest du deshalb den Umstieg auf WPF angehen. Das ist relativ einfach, wenn im bisherigen Projekt durchgängig mit Trennung von Design und Programmlogik und DataBindings gearbeitet wurde. Alternativ funktioniert im VS2022 auch die Oberflächengestaltung ohne den Designer, was aber nicht so bequem sein kann. Dazu kann man den betreffenden Code einfach ins Load-Ereignis einbauen. Wenn das nicht allzu viele eigene Steuerelemente sind, dann ist der Aufwand überschaubar.


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    • Als Antwort markiert norbert3 Donnerstag, 24. Februar 2022 09:37
    Mittwoch, 23. Februar 2022 21:11
  • Nochmals Danke. Formulare ohne Designer (Code ins Load-Ereignis) zu erstellen, ist in der Tat mehr als unbequem. Size und Location von Controls sieht man dann ja immer erst zur Laufzeit. Man muss ewig fummeln bis alles richtig sitzt. Mit WPF habe ich mich bislang überhaupt nicht befasst. Da muss ich mich erstmal einarbeiten. Ob wir damit die gesamte komplizierte Telematik Infrastruktur (FHIR, HL7 usw.) hinbekommen, macht mir schon Kopfzerbrechen. Aber da müssen wir im Moment ja nichts überstürzen.

    Grüße Norbert

    Donnerstag, 24. Februar 2022 09:37
  • Hi Norbert,
    Oberflächen mit WPF zu gestalten ist viel einfacher, es gibt viel mehr Möglichkeiten, ein modernes Aussehen kann erreicht werden, richtig aufgebaut sind WPF Oberflächen auch viel lebendiger, viele Details können deklarativ ohne Hintergrund-Code realisiert werden. Ich liebe WPF und nutze gern das MVVM Entwurfsmuster, in welchem Design und Logik vollständig trennbar sind. Wenn in alten Winforms-Projekten Design und Logik maximal getrennt sind, ist der Übergang zu WPF recht einfach. Kompliziert und aufwändig ist die Einarbeitung in WPF. Diesen anfänglichen Zeitaufwand darf man nicht unterschätzen. Für die ersten Oberflächen mit WPF solltest du mit mehr als dem 10-fachen Aufwand gegenüber der WinForms-Technolgie rechnen. Nach 3 Monaten intensiver Beschäftigung mit WPF sollte es keinen Produktivitätsunterschied bei der Gestaltung von WPF-Oberflächen gegenüber WinForms-Oberflächen mittels Designer geben. Nachteilig bei der Nutzung des Designers für WPF-Oberflächen ist, dass der Designer kein optimales Ergebnis liefert bezüglich automatischen dynamischen Anpassungen zur Laufzeit, z.B. nach Veränderung von Fenstergrößen zur Laufzeit, Platzanforderungen dynamischer Text (-längen).


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks


    Donnerstag, 24. Februar 2022 13:44