I'm having an issue with some UI Text objects in my company's project (sorry if I may not give some details, since I cannot share everything) where sometimes they break. In the print screen below I show you the editor window but this happens on runtime as well. In the editor I just need to target the window or move the view so they refresh but in runtime this is not so easily fixed.
Some details that might help:
These text components are dynamic and use a non-native font; I've
tried to use .SetAllDirty() after the changes but it won't work;
I've seen people speaking about clearing the characterinfo but
sometimes works others not;
I've also found a solution that pushes
them 10 units in the "z" axis but that doesn't smells me right. We
have lot's of text objects to pull and most of them are
instantiated;
Thank you for your attention towards this issue and for any solutions that you might give. I'll try to answer them as soon as I can.
Broken UI Text
Actually, this is a known bug of Unity.
I've also got this bug, but you can try to send a bug report to Unity.
You can send one by using the shortcut at the start menu. (Unity [version] > report a problem), if you don't see it, go to Unity, then Help > Report a problem.
Or you can try to report the bug to the issue tracker.
I am having a rather odd issue that I have been unable to find the answer to. I have 2 PCs that I am doing coding on - one a desktop PC and one a notebook (QuadHD resolution). Each has Windows 8.1 & Visual Studio 2013 Update 5 installed.
I have localized all my Forms and it seems that when I edit the Winform on my notebook, it causes very odd resizing issues to occur. For example, if I simply change the "Language" property from one language to another (that I have already translated), the entire form is skewed and re-sized, completely destroying all the layout of the form in the selected language. On another form, the "ImageScaling" property is erroneously changed from 16x16 to 40x40.
The issue seems to be related to the changing of the 'Language' property. Almost like there's some sort of resizing logic & layout logic being applied when this property is changed.
When I perform the same operation on my desktop PC, I get no such odd modifications (as I'd expect). This obviously renders my notebook completely useless for being able to do any WinForms work!
I initially thought this might be related to some quirk with the QuadHD display (i.e. 3.2k x 1.8k). I have tried to reduce the screen resolution to a regular HD quality, however this doesn't seem to resolve the issue.
Does anyone have any hints about what I could try to fix this problem?
Thanks.
The only workaround I have been able to come across so far is to ensure that your Windows Settings->Display->Scaling is 100% BEFORE making any modifications to the form (including changing any seemingly innocuous properties such as 'Language').
On high-resolution screens, this unfortunately makes the content almost unreadable but at least the forms are not completely ruined/resized when you edit them.
You will unfortunately need to do all your edits in this mode and commit them before reverting your scaling back to its original setting.
I know there will be folks who will vote this question down or ask for close. But if there is any kind of information or code I can provide you to know more about my program I will let you know. So please keep reading and see if you have had a similar problem.
I am running a Win7 64bit with .Net Framework ver 4.5.
I have created a Winform application. And to create my form elements I have taken advantage of a library called Metroframework that gives the program a metro look and feel. It contains some standard controls and as well as user controls that inherit from the original Form class. This is the opening view of my program.
However, for some strange reason, when I came to install my program on two other computers (one running Win7 and the other Win8), I noticed that some of my form elements have changed their location and some have just disappeared or just have been displaced. This has frightened me knowing the amount of time I have spent to put this elements in place.
Everything looks fine on my own computer both in dev environment and after building my application in release version. At first I thought this is a screen resolution problem on the other two devices, but that was not the case either. And even if it was, why should this happen?
Can anyone please help me solve this problem? I will share any part of my code you need. But I really have no idea where the source of this problem is!
The main influence on the layout variations on different machines is theForm.AutoScaleModeproperty.
In theory the default setting should work fine but I found that sometimes it is best to switch it off completely, that is going from Dpi or Font to None..
MSDN explains a little about the intended effect.
BTW: The is also a ContainerControl.AutoScaleMode property, so you could choose different modes for some parts of your forms as described here:
The AutoScaleMode property specifies the current automatic scaling
mode of this control. Scaling by Font is useful if you want to have a
control or form stretch or shrink according to the size of the fonts
in the operating system, and should be used when the absolute size of
the control or form does not matter. Scaling by Dpi is useful when you
want to size a control or form relative to the screen. For example,
you may want to use dots per inch (DPI) scaling on a control
displaying a chart or other graphic so that it always occupies a
certain percentage of the screen.
To remain true to the pixel-precise layout use:
this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.None;
The last value in the AutoScaleMode enumeration is Inherited which most often would be chosen for nested containers.
Update: The choice of ContainerControlsis rather limited:
System.Windows.Forms.Form
System.Windows.Forms.PropertyGrid
System.Windows.Forms.SplitContainer
System.Windows.Forms.ToolStripContainer
System.Windows.Forms.ToolStripPanel
System.Windows.Forms.UpDownBase
System.Windows.Forms.UserControl
Maybe the most useful is the UserControl. Note that it doesn't expose the AutoScale property in its instances but only in the class definition. Also note that you can't add controls to an instance in the desiger, but you could assemble them in maybe a Panel and then set a UserControl (with AutoScale=Font) to be the Panel's Parent.. You'll need to allow for some extra space in any case, though..
I have a WPF application, and it's slow.
It is NOT the rendering. Firstly, the rendering is quite simple, and secondly, I looked at it with WPF Performance Toolkit - nothing.
It is NOT in my own code. Firstly, the unit tests work fast, and secondly, if I replace all DataTemplates with blank ones, everything works fast.
So far, it looks like the slow part is template instantiation. That is, when you start the application, and open some complicated screen, it takes a lot of time. And by "a lot" I mean "a lot". Sometimes can be as much as 3-5 seconds - for example, when there's a datagrid with 100 rows. But when you go to another tab, and then go back to that same screen, it opens fast (as long as its viewmodel stays put).
This is very annoying not just because it's slow, but because I can't do anything about it. If I had some control over the slowness, I could, maybe, display some "opening, please wait" message or something...
Besides, when I look at some other WPF applications (most notably, ILSpy), they seem to work reasonably fast, despite the large amounts of data. This makes me believe that I'm probably doing something wrong. But I have no idea where to start.
Any ideas? Any classic mistakes? Any tips?
My exerience comes from working on the WPF mind mapping application NovaMind
A couple of months ago we completely rewrote our intermediate layer to solve the performance issues we had experienced. In a nutshell, creating our user controls seemed to be way to slow. Unfortunately I couldn't find a great way to profile the performance as neither the WPF Performance Suite nor commercial applications such as ANTS Profiler give you any detailed information on this part of the WPF process. (I asked this question back then)
We resorted to manually test our application by trial and error and removed parts of our user controls to see what exactly is the culprit.
In the end we solved the performance issues by completely rewriting our controls. We also cut down on the complexity of our visual tree dramatically. Before the rewrite, one of our most used user controls, when inspected with Snoop, consisted out of 61 different things, now there are only 3. Wherever possible we only added things to the visual tree on demand. (As you know in XAML even when you set things to Collapsed, they need to be created first).
Finally we were forced to write our own rich text rendering control as the built in RichtextBox is ridiculously slow and the visual tree of the RichtextBox is quite complex.
I don't know if this will apply to your situation but I would recommend that you investigate your user controls and see if they are complex. Maybe you have things that you could trim.
Low hanging fruits would be parts that are only rarely visible or can be created in a lazy manner. You could create these parts from code behind when necessary rather than having them in XAML. This should help you a lot.
Otherwise virtualization is your friend, if possible. In our case we couldn't do that unfortunately.
This sounds similar to a problem i was having. I posted the fix here: WPF UI Automation issue . Just posting for the benefit of searchers, as it took ages to resolve.
Following comment on link only answer, here is the crux of that post:
I did the following:
Downloaded Hotfix - - http://archive.msdn.microsoft.com/KB978520 (may not be required)
Downloaded Hotfix - - http://archive.msdn.microsoft.com/KB2484841 (definitely required even if you have Windows 7 / .NET 4)
Improved the code further (the validation was causing an excess of objects) - Why does WPF Style to show validation errors in ToolTip work for a TextBox but fails for a ComboBox?
It may be that only Number 3 was required, but it worked. Just posting here so people dont lose the days I lost in memory profilers etc.
User Control in your data template, is not completely bad idea but if you crave for performance then you should consider switching to lighter control. For example, having a UserControl just hosting a TextBox is very bad idea, as UserControl is made up of ContentControl, ContentControl hosts ContentPresenter and ContentPresenter will host TextBox so if you notice your Visual Tree, it has three new layer of UI Elements. Reducing Visual Tree will certainly improve the performance.
Most likely, I would suggest creating Custom Controls that may be a completely a new control having few dependency properties that can relate to data you want to present and you can have its own custom template in generic.xaml. Second, you can just simply derive a control from existing controls and redefine its default template in generic.xaml.
This approach will certainly work better as you will be reducing your Visual Tree, thus reducing Visual State Manager's job.
Changing theme or template will be slower then changing the element that hosts content. And let the element have the default template in its own generic resource dictionary.
Try moving all the resources up as
far as they'll go, preferably into
app.xaml
Check if you could use StaticResource
instead of dynamic ones, static ones
are alot faster
If possible, try using depedency
properties in your VMs, especially if
you have alot of them at once or if
they have alot of properties. That will keep wpf from having to do a bunch of reflection.
You mention you are using a DataGrid with, say, 100 rows. A likely culprit of your perf problems is that whatever datagrid you are using isn't doing virtualization, and so your visual tree is gigantic.
Normally, long startup time in WPF screens points to a large visual tree.
I'm not sure if you're using a datatemplate per row, or some 3rd party grid that binds columns, or what - but lets say you have 8 columns with controls. Depending on your grid/validation/etc, this could be a visual tree of 20-60 items per row. If you have a combobox, then each item in the dropdown may be created per row as well.
To fix this just takes watching the details, and taking measures as you go:
Use a virtualizing control as much as possible. This means using a virtualizingstackpanel inside list controls, and making sure your 3rd party controls do as well (many stock WPF controls do now by default)
Do not overuse UserControls, composite controls, etc. Adding depth adds time, and putting in extra visual tree depth in a datatemplate or other repeated area adds up fast.
If all else fails, show a simple screen and add controls through code to improve perceived performance
I have written several WinForms apps in my life, and every once in awhile something will go wrong with the layout at run-time. Today, while I was fiddling with the fonts in my application (mainly whether fonts were bold or not), I found that a control (which was anchored to all four sides of a TabPage) was extra-wide at runtime, going beyond the right edge of the page. I fiddled with the fonts again and the problem disappeared. Then I tried to replicate what I thought caused the problem in the first place, but it did not recur.
Another problem I sometimes have is that a Form with no MaximizeBox will randomly start maximized--maybe not on a development machine, but on a user's machine.
Can anyone tell me if they've had one of these problems and found the cause or solution?
Make sure you are familiar with the Anchor and WindowState properties, and set them to the correct values.