infragistics winforms controls don't scale - winforms

I am using some controls from Infragistics2.Win.v10.3.Design . I know that this is not the latest version, but we haven't migrated to later versions yet.
The problem is that I have a windows forms control on which I have few UltraCalendarCombo controls. They don't scale and don't change their position when I change container control's AutoScaleMode to Font or to Dpi. What should I use to scale them? The font inside those controls scales well, actually. Should I resize them manually?
Or maybe the controls from this library are for .NET 1.1 FW, so that's why they don't support AutoScaleMode properties of their parent controls? Our application is compiled for .NET 4.0 FW.

I tested this with a UserControl and didn't reproduce the behavior. If your control that you have created derives from ContainerControl, then you should get this behavior automatically in .NET 2.0 or later. See Automatic Scaling in Windows Forms for more details.

Related

WPF native controls in Xamarin

I was playing around with Xamarin and WPF after following the BoxViewClock tutorial from the Xamarin website but apart from that one article, which has been duplicated on a number of sites I cannot find any other advanced examples.
Is it currently possible to add/use a WPF custom control to an xamarin forms page? or for that matter a view/user control?
You typically start creating a custom control by deriving from one of Xamarin.Forms controls and you do it in shared .NET Standard library with Xamarin.Forms UI project. As soon as there's behavior which is not feasible within Xamarin.Forms you create a native renderer in a project targeting specific platforms, in our case in WPF project. Thus there're 2 steps for creating custom controls in Xamarin.Forms:
Derive from existing Xamarin.Forms controls in Shared project
Add extensions to it via platform renderer (or behaviour which is a custom case of renderer) in platform project.
You can find example of creating "ExtendedLabel" control which adds to the standard Xamarin.Forms' Label with capability to change cursor to Hand when mouse hovers over the label in WPF application:
Xamarin.Forms control: https://github.com/maxim-saplin/CrossPlatformDiskTest/blob/master/Saplin.CPDT.UICore/Controls/ExtendedLabel.cs
WPF platfrom renderer: https://github.com/maxim-saplin/CrossPlatformDiskTest/blob/master/Saplin.CPDT.WPF/ExtendedLabelRenderer.cs - you can ignore the code after "if (label.FormattedText != null &&..." which is a workaround for a bug in Xamarin.WPF and not related to the questions
P.S.: in the repo there's also a renderer for macOS which implements the same behaviour

Odd WinForm behavior after introduction of WPF control

I recently introduced a WPF control to my VB.net WinForms application. The control looks good and works great. However, depending on which environment I run the application, I will get different behavior. The two machines that differ are both running Windows 8.1 with the default theme.
I have read a few questions about adding proper theme settings and I don't believe that is the issue.
In the environment that is incorrect I have observed the following behavior:
Upon loading the form containing the WPF control, the calling form will resize and move around the screen
Controls contained within the form that also contains the WPF control will often "ghost" upon resizing the application
Both the calling form and the form containing the WPF control shrank upon loading the containing form. By shrank I mean window size, control size of all controls, font size, etc...
I'm wondering if the application was built against one version of the library and the DLL versions differ on the deployment environments. But I'm not sure how to look for this.
Has anyone encountered this before?
I found the problem.
This was the result of DPI scaling. The application was acting out anytime the DPI settings were set to anything other than 100%. WPF controls scale differently from Winform controls causing the strange behavior. The following stackoverflow Q/A explains how to remove the DPI dependency
Disable DPI awareness for WPF application

Using WPF controls in a Surface application

I'm needing a TreeView control in our surface application. Situation is ive already created a TreeView implementation using infragistics XamlDataTree. Im wondering whether this control set can be used in a Surface application (being that it is a WPF app under the hood)?
Question also in general can you reuse standard WPF controls in the surface environment?
Also is there a tool already in the Surface SDK suite that would suit a TreeView style layout?
Thanks in advance
Don't know about the XamlDataTree, but in general, you can use any WPF control in a Surface Presentation Layer Application.

Why do I see pixels when zooming WPF application in Windows?

I have developed a GUI for a random application using WPF. I have a bunch of out of box WPF controls laid on the application window. I haven't customized anything, didn't use bitmaps, etc.
When running my application and zooming using Magnifier application in Windows 7 (Win key + Plus key, the magnified GUI is showing pixels.I am probably wrong, because I can't explain it otherwise, but isn't WPF supposed to provide vector like control rendering?
Thanks for participating in the discussion.
Bonus Reading
Tim Sneath: Magnifier: An Interesting Discovery (archive)
WPF Vector based interface *(screenshot of WPF being vector scaled by Magnifier)
MSDN Blogs: Greg Schechter explains why it longer happens (archive)
Back when Vista first shipped, and when WPF was on version 3.0, zooming with the built-in magnifier would actually do vector-based scaling.
This stopped working when WPF 3.5 service pack 1 shipped. (It worked in 3.5 before sp1.) The reason it worked before then is that the DWM (Desktop Window Manager) - the part of Windows responsible for presenting everything you see on screen - uses MILCORE.DLL to do its rendering. Version 3.0 and 3.5 of WPF also used this same component to render - this meant that all WPF content was native content, so to speak. (In fact, on Windows XP, which doesn't have the DWM, MILCORE.DLL is something that WPF puts on your system for its own benefit. But it's built into Vista and Windows 7.) When WPF was using MILCORE.DLL to render on Vista, any effects applied by the DWM such as scaling would also apply in the way you want to WPF - it really did scale without pixelating.
Unfortunately, this is no longer the case. And the reason is that WPF started adding new rendering features. In 3.5 sp1, the new feature in question was support for custom pixel shaders. To enable that, Microsoft had to release an update to the MIL. (The Media Integration Layer - the bit that does the actual rendering.) However, they weren't really in a position to update MILCORE.DLL, because that's part of Windows - it's how everything you see on screen gets to be on screen. Releasing a new version of MILCORE.DLL effectively means pushing out an update to Windows. The release schedule for Windows is independent of that for .NET, and so the only way the WPF team could reasonably add new features was to ship a new MIL. (In theory they could have done it via Windows Update, but since WPF is now owned by a different division of Microsoft than Windows, that sort of thing doesn't seem to happen in practice.)
As of .NET 3.5 sp1, the MIL is in a different DLL called wpf_gfx_vXXXX.dll where vXXXX is the version number. In .NET 4.0, it's wpf_gfx_v0400.dll.
The upside is that WPF gets to add new rendering features with each new version, without needing Windows itself to be updated. The downside is that WPF's rendering is no longer as tightly integrated with Windows as it was briefly back when Vista shipped. And the upshot is, as you've seen, that magnifying is not as much fun as it used to be.
The magnifier application implements its own zoomed image rendering, so that's why you are seeing pixels. WPF does use vector graphics, but in this situation it's not the WPF application itself that is rendering the zoomed image.
If you use something like Snoop you can see zoomed and scaled WPF vector graphics rendering in action.
I suppose, Windows 7 magnifier takes a snapshot of actual application on-screen UI, and then magnifies it itself (not making a special case for WPF applications). Of course what it can access is just the pixels, not the vector graphics which works behind the scene.
The Windows-7-Magnifier is pixel based, but there is a difference in magnifier mode depending on wether an Aero-theme is active or not.
with Areo theme the zoom is pixelated.
without Areo theme the zoom is smoothed (blurry).
Only with Areo theme other Views (except "Docked") are selectable.

changing Visibility to hosted winForms element in wpf application

I have ReportViewer winForms control for showing Microsoft Reports in my WPF application hosted over WindowsFormsIntegration.
When the MouseDown event of my textBlock triggers, I would like it to fade lets say from 0 to 100 visability, like some other elements in my Window. It doesn't, so I was wondering is it the same for all hosted controls or this one specific and how can it be solved?
Regards,
Ivan
The WindowsFormsHost supports Transparency. But some WinForms Controls do not.
See the Supported Scenarios in Windows Presentation Foundation and Windows Forms Interoperation article on MSDN. Especially the first row in the "Behaviour" table:
Some Windows Forms controls do not
support transparency. For example, the
TextBox and ComboBox controls will not
be transparent when hosted by WPF.

Resources