I was wondering, is there a consequence to embed a Windows.Form element in a WPF application ?
I don't really know the difference between both architectures, but mixing them can have negative impacts ?
There are always consequences with such choices.
Mainly winform doesn't support wpf event mechanism for bubbling event and dependency properties, you have to wrap it up if you want to use some binding and follow the MVVM pattern.
Besides, it will not be a part of the visual tree if I remember well. It will create an other form over the form of your application, i.e. an other window handle...
Not impossible, but You got to wondering yourself If it is worth it.
Related
I have a Xamarin app. (Only) for the UWP app I need access to the mouse events (PointerMoved- / PointerEntered / PointerPressed-Events).
Until now my entire codebase is shared code.
Can somebody help me with forwarding the mouse events to the shared Code base? I googled a lot and nearly all answers either suggest a paid libary called "MR.Gestures" or say that it is not possible to recieve mouse Events (like this one I am not able to implement MouseUp, MouseDown and mouseMove Events in Xamarin Mobile applications). Sometimes GestureRecogniser are mentioned, but they Arent extensible, so how are they supposed to help?
Is there really no way to recieve mouse Events in xamarin?
You can do this. However it is a very extensive work to the level that you might consider to write your app in the native UWP XAML and share some C# code with the Xamarin project instead.
The way would be to extend each control that you are going to use (yes every single control that needs this effect), add to it those events and then write the UWP custom renderers that would invoke those events and then replace all controls in your XAML with those controls.
As said this may turn to be quite extensive work, but that's how it can be done.
Also if you don't need those events but just some visual effects on those events it may be possible to cut on this work by writing a custom XAML styles for those controls in app.xaml in the UWP project.
During an interview, the company was asking about my use of custom controls in WPF. I have found with all of the power of the WPF way of creating a control (datatemplate, control template, styles,triggers etc... ) that having to write a custom control that overrides the OnRender method really hasn't been necessary. Later found out that most of their development has been in Winforms.
If coming at a control from a 100% WPF direction, how often is it necessary to write a customcontrol with OnRender overrides? The Winform approach is really not making use of the WPF composition technique of creating controls and it seemed like a question not based on much WPF knowledge.
Thanks
Harold
Good question (though a bit opinion-based) and no answers? Fixing.
If you are winforms-experienced developer, then thinking winform-way is still acceptable in wpf. For a while. This is where you may find self making mostly custom controls (containing xaml and code, or even without xaml). But the more you learn, the less you need that. Many many tasks can be completed in wpf simply because it is very flexibly. Every entity consist of something what can be customized: templates, styles, converters, behaviors or even plain event handling.
You can start with custom control and then find out what you don't really need it (or it can be downgraded to simple restyling).
When I started making first serious wpf project, there were 3 custom controls and they are still. Here is why.
Outlined TextBlock. Simply because you need custom OnRender (to build and draw geometry for outline).
Animated content. To apply transition animation when changing content. I could almost make it without custom control, but there is a problem - calculating animations logic when transitioning left-to-right, right-to-left, up-down or down-up. It's waaaay easy to have in one custom control. But possible with UserControl and view, not as pretty still.
Graph. Simply because it's too complicated to be presented with Visual and because of performance using gdi+ gives millions of points (hundered thousands figures) to be drawn within ms.
Conclusion: it's good and useful, though way less than it was in winforms (where you simply had no other option).
I'm currently developing an Windows Forms application in C# which will make use of tabs for the GUI. The problem I'm facing though is that the code is becoming untidy.
The reason is that the code for GUI components (such as button clicks) resides on the main form code.
So I'm looking for a way to still handle all the GUI interactions the same way but separate the code in a logical way (e.g. different files). Like having button1_click() reside in another file but work the same way as before.
Thanks :)
You can place each "Tab" into its own UserControl, and handle the events there instead of all within the main form.
As tabs typically each represent something "distinct", this is often fairly simple to implement, and helps clean up your code.
I have a winform application that I want to convert to WPF
It has a main form (MDI) and the children can call each other as well.
I read that MDI is not a good practice according to the mvvm. But I saw that application have the look and feel that I want (e.g:Prism- I was told that it is too complicated for beginners and for a small application like I need).
Do you know a small WPF project that follow the mvvm rules and has the look and feel of MDI application?
Thanks
Asaf
MDI is a GUI design pattern. MVVM is a programming design pattern. The two really aren't related at all. You can do either one or both together.
It is true, however, that many GUI design experts frown upon MDI but that's entirely because of usability for the end-user... not because of the underlying code.
Perhaps if you describe or provide a mockup of the UI you want to create we can provide guidance on how to implement it in WPF.
Can IDataError info be used properly in a winforms application? In the past I was doing my binding the usual way(1) and did the validation in the OnValidating event of the particular control. I would like to move the data validation to the domain model so that I can easily swap out user interfaces and so that all of the logic is in one place.
I was looking into IDataErrorInfo but everything I find deals with WPF and the app in development is strictly a winforms app.
I also noticed that the binding that gets used in WPF is in System.Windows.Data and the binding that I've always been using is in System.Windows.Forms (which I don't appear to have when I try to add it as a resource - I'm using 3.5).Aside from the property "ValidatesOnDataErrors" is there a difference between the two?
(1) the usual way being:
myControl.DataBindings.Add(new Binding("Text", this.domainModel, "Property"));
This works with the ErrorProvider component in Windows Forms.
For a complete, but very simple and short tutorial, see this blog post.
Yes, IDataErrorInfo works in winforms. For example, DataGridView will use this automatically both per-row and per-cell. But it is implementation-specific, and isn't automatically applied to other bindings. I did once write some code to associate it to an error-provider and do the work via change events, but I don't have it to hand unfortunately. But I seem to recall it wasn't huge.