Verwenden .NET Windows Forms-Anwendungen die entsprechenden nativen Win32-Steuerelemente für grundlegende Steuerelemente wie Textbox und Button? WPF ist nicht nativ, Windows Forms sieht jedoch sehr nativ aus. Die Animationen auf dem Button-Steuerelement sehen genau wie eine Win32-Schaltfläche aus.Sind grundlegende Windows Forms Windows steuern native Win32-Steuerelemente?
Antwort
Ja, sie sind & hellip; mit ein paar Ausnahmen.
Einige Dinge in WinForms sind benutzerdefinierte gezeichnet. Sie verwenden das native Steuerelement, aber sie aktivieren Owner-Draw und behandeln einige Zeichenlogik intern in C# -Code. Der Vorteil besteht darin, dass Elemente wie Schaltflächen eine BackColor
-Eigenschaft haben, die eine benutzerdefinierte Farbe anstelle der Standardsystemfarbe unterstützt. Im Allgemeinen sollte dies vermieden werden (zumindest meiner Meinung nach), weil nicht nur der Effekt hässlich ist, es gibt wahrscheinlich einen Grund, warum der Benutzer das Farbschema wählte, das er tat. Aber Grafikdesigner denken oft, dass sie es besser wissen als Benutzer, also gibt es die Option.
Bei Steuerelementen, die auf diese Weise implementiert werden, ist häufig eine FlatStyle
-Eigenschaft verfügbar, mit der Sie ändern können, wie sie gezeichnet werden (z. B. ButtonBase.FlatStyle
). Mit FlatStyle.Standard
führt das .NET Framework seine normale Besitzerzeichnung aus, auch wenn Sie keine der Eigenschaften des Steuerelements mit ungewöhnlichen Einstellungen angepasst haben. Mit FlatStyle.System
wird das Steuerelement direkt von Win32 gerendert, ohne Owner-Draw oder andere Außerkraftsetzungen.
Sie können den Unterschied auf Tasten ziemlich leicht erkennen. Wenn der Wert auf FlatStyle.System
eingestellt ist, blendet der blaue Hover-Effekt der Tasten allmählich aus und aus. Bei Einstellung auf FlatStyle.Standard
erscheint das blaue Leuchten plötzlich und verschwindet. In der Nähe, aber nicht ganz gleich. Kombinationsfelder tun dasselbe (zumindest wenn ihre DropDownStyle
-Eigenschaft auf ComboBoxStyle.DropDownList
eingestellt ist).
Ich empfehle, alle Steuerelemente, die eine solche Eigenschaft haben, auf FlatStyle.System
einzustellen, es sei denn, Sie benötigen unbedingt ein Verhalten, das von diesem FlatStyle nicht unterstützt wird.
Es gibt ein paar andere Ausnahmen. Einige WinForms-Steuerelemente sind in Win32 nicht vorhanden, sodass sie nicht von systemeigenen Steuerelementen unterstützt werden. Die DataGridView ist ein gutes Beispiel für eine solche Kontrolle. Die MenuStrip und ContextMenuStrip Steuerelemente werden schließlich vollständig in C# -Code geschrieben und manuell von WinForms gezeichnet. Sie werden von nativen Win32-Steuerelementen in keiner Weise gesichert. Aus diesem Grund sehen sie auf Windows Vista und später so schrecklich hässlich aus, weil sie für immer den Office XP-Stil festhalten. Es sah auf Windows XP cool aus, aber es ragt bei späteren Versionen wie ein wilder Daumen heraus. Das Ändern des Renderingstils von Professional
zu System
hilft auch nicht sehr.
Stattdessen müssen Sie die ursprünglichen Versionen dieser Steuerelemente, MainMenu und , zu Ihrer Toolbox hinzufügen. Sie sind nicht standardmäßig in den neuesten Versionen von Visual Studio enthalten, aber sie sind absolut immer noch verfügbar und werden nirgendwohin geführt. Auch hier empfehle ich dringend, diese zu verwenden, da sie zu 100% von den nativen Win32-Menüs unterstützt werden und daher unabhängig von der Windows-Version Ihres Benutzers so aussehen, wie sie sollten.
- 1. windows forms
- 2. IPC Windows Service Windows Forms
- 3. Windows Forms: Windows-Label nicht
- 4. Windows Forms-Anwendungsleistung
- 5. Windows Forms: Mehrere Standardschaltflächen?
- 6. Registerkartenindex in Windows Forms
- 7. Refactoring Windows Forms-Anwendung
- 8. SignalR in Windows Forms
- 9. Windows Forms - ErrorProvider + DataGridView
- 10. Windows Forms RichTextBox Cursorposition
- 11. Windows Forms MenuStrip Rahmenfarbe
- 12. Windows Forms Endlosschleife Ausnahme
- 13. Klassenname in Windows Forms
- 14. Windows Forms, Lernprogramm?
- 15. Windows Forms - Berichtsdesigner
- 16. AddMessageFilter ohne Windows Forms?
- 17. Windows Forms Sichtbarkeitsproblem
- 18. Speicherauslastung: WPF vs Windows Forms
- 19. Windows Forms Kontrollkästchen mit LINQ
- 20. Windows Forms Skins in C#
- 21. Windows Forms Elemente - Swap Spots
- 22. native Windows-Anwendungsentwicklung Optionen
- 23. Windows Forms klein MenuItem hitbox
- 24. Was sind die häufigsten Entwurfsmuster für jede Windows Forms-Anwendung?
- 25. SharpDX, DirectWrite und Windows Forms
- 26. Windows Forms: Textbox mit Geschichte
- 27. Markieren von Beschriftungen Windows Forms
- 28. WPF mit Windows Forms - STAThread
- 29. Windows Forms C# .net Bereitstellungsproblem
- 30. C# -Threading und Windows Forms
+1 interessant. Hast du eine Referenz dafür? –
@Jay Nicht wirklich, nein. Die Dokumentation gibt einige Hinweise, ebenso wie die Referenzquelle. Aber die beste Referenz ist meine Erfahrung. –