Hi Dick,
unfortunately you were not in my session at the X# Summit were I said clearly that there is no unique solution for all GUI needs.
In fact, we internally are using the VOGUI classes, Windows Forms and WPF for the development of new applications.
So everyone has to select what he thinks fits best his needs.
I have also tried to use WPF on the "classical" VO way (filling the windows manually and saving back also manually), but after knowing databinding I felt I loosed to much.
And I agree that the WPF window editor is not filling all the expectations, and sometimes has strange effects. But unfortunately this editor tries to start a visual editor for something that is not made for visual editing.
I was thinking several time how to build a WPF editor, and IMHO the only true possibility would be to have a treeview for the editing on the one side and a preview on the other side. But that would be too far from what most Visual Studio users would expect.
Wolfgang
Interest in WPF/MVVM Framework in X#
Moderator: wriedmann
Re: Interest in WPF/MVVM Framework in X#
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Re: Interest in WPF/MVVM Framework in X#
I'd be interested in an example project and/or short walkthrough of setting up the project. It seems WINUI 3/Windows App SDK and MAUI are Microsoft's most official GUI development frameworks, but WPF is mature and well supported (and not as dependent on .NET 8+ or recent Windows releases).
WYSIWYG isn't really possible or necessary due to different display dimensions, orientations, scale factors, not to mention strings resizing when switching languages. I just try to get used to stackpanels and grids, minimize absolute sizes and positions, and try to make the adaptable layout work for me more than against me.
MVVM doesn't thrill me all that much. I do know the difficulty of working in giant one-file-does-all view controllers, but separating concerns into different files does not reduce them, it just makes you navigate among more editor windows. Maybe we need a new approach to code editing, to escape the files and lines approach. Or maybe a few tweeks to the Solution Explorer to bring related items closer together.
View models still need coupling to the view via events and control properties, whether it is explicit or hidden behind commands and bindings. I ran into ugly holes trying to use databinding in Windows App SDK - the template-generated navigation system unloads views with a heavy hand without removing focus from a TextBox with changes or otherwise notifying the view model to manually update bindings, so changes could be lost. Oh, well, I'm trying to let MVVM grow on me. Although I rather like Uno's "C# Markup" approach (https://platform.uno/docs/articles/exte ... rview.html) - they made a lot of chainable extension methods, so your view class constructor looks quite a bit like the XAML tree representation.
WYSIWYG isn't really possible or necessary due to different display dimensions, orientations, scale factors, not to mention strings resizing when switching languages. I just try to get used to stackpanels and grids, minimize absolute sizes and positions, and try to make the adaptable layout work for me more than against me.
MVVM doesn't thrill me all that much. I do know the difficulty of working in giant one-file-does-all view controllers, but separating concerns into different files does not reduce them, it just makes you navigate among more editor windows. Maybe we need a new approach to code editing, to escape the files and lines approach. Or maybe a few tweeks to the Solution Explorer to bring related items closer together.
View models still need coupling to the view via events and control properties, whether it is explicit or hidden behind commands and bindings. I ran into ugly holes trying to use databinding in Windows App SDK - the template-generated navigation system unloads views with a heavy hand without removing focus from a TextBox with changes or otherwise notifying the view model to manually update bindings, so changes could be lost. Oh, well, I'm trying to let MVVM grow on me. Although I rather like Uno's "C# Markup" approach (https://platform.uno/docs/articles/exte ... rview.html) - they made a lot of chainable extension methods, so your view class constructor looks quite a bit like the XAML tree representation.
Re: Interest in WPF/MVVM Framework in X#
Hi Mark,
I have to prepare an example in the next weeks, and I will share that here.
As I wrote in 2023: WPF and MVVM in pure X# without any "foreign" framework is what I do for brand new applications.
Wolfgang
I have to prepare an example in the next weeks, and I will share that here.
As I wrote in 2023: WPF and MVVM in pure X# without any "foreign" framework is what I do for brand new applications.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Re: Interest in WPF/MVVM Framework in X#
Wolfgang,
Thank you! I'm trying a little MVVM WPF+XSharp+EF+Community Toolkit project now (https://github.com/mstasak/VSSolutionCatalog). I guess I'll learn whether XSharp can handle EF's attributes and schema migration tools or if that will require mixing in some C# or dropping EF altogether. Maybe I'll make two alternative model variations based on plain ADODB and X#.
Edit: annotations and partial classes seem to work fine, I'm impressed and pleased! Class docs seem a little weak, could use some clear translation guidance between .NET and XSharp syntax for members. But I really just need to read some clean XSharp code to get used to it. And grr, EF 6.x has dependencies with significant security issues.
Mark
Thank you! I'm trying a little MVVM WPF+XSharp+EF+Community Toolkit project now (https://github.com/mstasak/VSSolutionCatalog). I guess I'll learn whether XSharp can handle EF's attributes and schema migration tools or if that will require mixing in some C# or dropping EF altogether. Maybe I'll make two alternative model variations based on plain ADODB and X#.
Edit: annotations and partial classes seem to work fine, I'm impressed and pleased! Class docs seem a little weak, could use some clear translation guidance between .NET and XSharp syntax for members. But I really just need to read some clean XSharp code to get used to it. And grr, EF 6.x has dependencies with significant security issues.
Mark
Re: Interest in WPF/MVVM Framework in X#
Hi Mark,
since my software has to remain working for many years (I have VO applications that are in use for more than 25 years now), I have opted to not use any MS toolkit like EF that get discarded often, or presents several security issues.
And I use plain X# code to build my WPF windows.
In XIDE there are some of my sample WPF applications to understand how I mean that.
For me it is essential to understand completely how and why my code is working.
Wolfgang
since my software has to remain working for many years (I have VO applications that are in use for more than 25 years now), I have opted to not use any MS toolkit like EF that get discarded often, or presents several security issues.
And I use plain X# code to build my WPF windows.
In XIDE there are some of my sample WPF applications to understand how I mean that.
For me it is essential to understand completely how and why my code is working.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it