Code Red > .NET

Converting WinForm to WPF Window

(1/2) > >>

Jeff_M:
Is it supposed be this difficult? It took me about 6 hours to read & watch a number of learning resources on WPF, then recreate the form to WPFwindow. Visually it appears to be mostly what I need, see images. However, getting all of the comboboxes, checkboxes, text boxes, etc. filled with saved data and to react as needed when one is changed is proving to be a challenge. Why couldn't the developers have used the same naming process for the properties, methods, events, that WinForm controls had when creating WPF?

I've been working on just this 1 form now for 3 days, off & on, and it's still only about 75% done. I have about 90 of these forms to eventually convert, some less involved, some have a lot more controls. Now, you may ask, why am I doing this exercise in futility? Well, thanks to how WinForms don't always resize correctly when used on HiRes monitors with the Windows font scaling set to anything other than 100%, I'm finding it necessary to go this route.

If anyone has any suggestions on how to accomplish this in a bit quicker/smoother fashion please feel free to chime in.

n.yuan:
Jeff, I experienced the same frustration when started with WPF. As long time Autocad programmers, I believe most of us were more used to Win Forms. We usually jumps into UI to quickly build a prototype of supposed tool and show it to the business side for further discussion, and we often think through the process in OO way after quite some UI work.

IMO, it would not make too much sense to use WPF without doing it in MVVM pattern (except for super simple UI as dialog box). With MVVM, one should starts with ViewModel. Only when a meaningful ViewModel is available, the view then could be materialize by binding ViewModel data to it. Surely you can hard-code some bind-able properties of the view model with fake/test data, so that the view actually shows as expected, especially if the view has to show a collection of objects, such as ListBox, ListView, Grid,...

As for your particular UI as you showed, since it does not show collection of objects, so you still can go ahead to work on XMAL to make the UI runnable/showable. For combox, you can hard-code combox items in the XMAL for example. But you must get all the data required for this UI into ViewModel and expose them as bind-able properties correctly.

For me, if the UI if modeless window/PaletteSet, I use WPF exclusively. If it is modal UI, I only use Win Form if it is fairly simple, and no action is needed in AutoCAD when the UI is displayed.

One thing is for sure, even one is quite familar with/good at WPF/MVVM, it definitely takes more time to use WPF than to use Win Form. I'd the frustrated feel was quite similar when we VBA programmers first tried .NET API 15 years ago: suddenly you felt not being productive as you used to and so much to learn to do almost the same thing(well, we only realized that we could do more with the pains-taking learning). I am glad I can stick with WPF for most my AutoCAD UIs these days.

Not really suggestion on how to do it, Just share some thoughts/feelings.

huiz:
I agree with Norman. I started too using WPF as it was WinForms. Still learning and I regularly smash my head on the desk but now  I do not want to go back to WinForms.

Jeff_M:
Thanks guys, I feel a bit better about this knowing that you also felt/feel frustrated at the learning process. I  think I will start wearing a helmet to protect forehead from desk.

huiz:
I just spilled two days designing a combobox with custom items. I tried to show two lines of text and an image in the combobox and the list below. The opened list showed the items as designed, but the combobox was empty. The code got more and more complex with bindings, converters, style triggers, but nothing helped. Finally I started over without any styling and now it works as designed. Slowly adding styles and binding options now.


Then I styled the tooltip on the items. It pops up on each item in the list but not on the combobox. Moved the tooltip to a datatemplate so it could be used in the combobox and the list below, without the need to design it twice. Then I found out it pops up also when the combobox is not filled. I solved that with a style trigger that sets the TooltipService.IsEnabled when the SelectedItem is null.


But now it works and it looks good. But again I have a blue stain on my forehead from smashing on the desk. Long story short: WPF is horrible to implement, but the result is worth it. It is actually designed for non-programmers. The programmer doesn't need to dive in the design and the designer doesn't see the code. But since we both program and design, we have to work in both worlds.

Navigation

[0] Message Index

[#] Next page