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.
Related
I am modifying a Winforms application to be accessible via Dragon Professional 15. I have also recently added support for screen readers (including JAWS and MAGic) so the application has been, for the most part, reviewed in order to ensure that the AccessibleName (and, where appropriate, AccessibleRole) property is filled out.
Dragon does fairly well with most of this application but there are parts with which it utterly fails to operate. After a lot of trial and error, I was able to determine that the cause of the problem was the use of TableLayoutPanels in my application. Any control that resides in a TableLayoutPanel is not consumable by Dragon (ie. when I speak the AccessibleName value, Dragon cannot find the control). As an example, the button in this document tree works just fine in the following configuration:
(NB: The noFocusCueButton class derives from Button and has only minor changes concerning visual aspects of the class.)
In this configuration, I can speak the AccessibleName of the noFocusCueButton and Dragon will recognize it and click it. However, as soon as I move to this configuration:
...Dragon can no longer detect and interact with the noFocusCueButton. I have searched for some property on the TableLayoutPanel that might explain this but I do not see anything obvious. I have also searched for other people encountering this problem but have not come up with anything. Any SO experts out there know anything about this?
In what can only be described as "the story of my life", I found the problem in less than a few minutes after posting the question (though I had spent hours on it beforehand).
Evidently, at some point, the AccessibleRole property of the TableLayoutPanel had been set to List. Setting it back to Default fixed the problem.
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.
We have a complicated legacy form built in Winforms that recently has started seriously misbehaving and it gets worse and worse as time goes on. Just opening the form in design view will alter the layout of the form, sometimes in minor ways (a control is resized to be a pixel smaller) and sometimes in major ways (a component is moved to X position -6582). Due to the size of this form and the nature of the generated .Designer.cs referring to the diff is almost usually useless to determine whether the changes that were made to the form were the changes that you actually intended.
Based off a number of suggestions I found in other questions:
visual studio 2005 designer moves controls and resizes Form
Visual Studio keeps resizing my form without me telling it to, help!
Controls moving in vs2008 design mode on build
AutoScaleMode is set to None. I experimented briefly with various monitor resolutions, to no avail. Ultimately we decided to stop relying on anchors and instead use a combination of TableLayoutPanels and Dock properties. And that's when the trouble really started...
After heavily redesigning one of the hairier tabs on this form, when I tried to save Visual Studio spun for 2-3 minutes and reported "Could not load file or assmbly 'MyProject, Verion=X.X.X.X, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified" (as seen here: Visual Studio 2013 Can't save, build, or rebuild solution). This happened whenever the form attempted to save. After following the advice in the accepted answer, I was able to save/build again.
Attempting to run not much later resulted in a very, very long build time and a completely empty form (as seen here: All controls on a form are invisible and https://stackoverflow.com/a/5524183/1015495 ). All calls to Controls.Add had been removed from the designer (I assume this massive change is what resulted in the long build time). I restored the form to a previous version and began recreating my changes. Now, much more insidiously, certain controls have had all of their children removed.
Working within this form is becoming a timesink at best and unfeasible at worst. The solutions that I've found online basically boil down to "recreate the form manually" or "don't use Winforms". Unfortunately neither of these are an option right now. How can we mitigate the problems that we're having with this form in the mid-term future until we can come up with a proper fix?
I am working through an almost identical problem at the moment and mine seems to be a bug in Visual Studio 2013 related to having a "linkLabel" control on a User Control, which is on one of the tabs of a tab control on the main form.
I had other linkLabel controls on the parent form that did not cause any issues. The weird thing is that not ALL of the tabs were messed up, only some of them. I can only conclude that it gets through part of the layout restructuring, hits the user control, and bombs out, failing to finish the layout correctly. I attached a second version of visual studio to try to catch exceptions, and saw various status lines showing up in the debugger, but did not see any exceptions thrown. I am not that familiar with doing that, so it's possible I did that wrong though.
I could revert the code back to after I had added the user controls, but before VisualStudio opened the form in the designer and automatically re-generated the designer code. At this point, opening the form in the designer will always cause exactly the same design failures. As long as I never opened the code in the designer again, everything would work correctly at run time.
If I removed any reference to the custom user controls with link labels, the designer would also open without any trouble. At first I assumed I had an error in my own code so I started commenting things out, but it was still happening even with just the basic elements dragged on. So then I started removing elements and adding them back one at a time to see what broke it. In my case this turned out to be the "linkLabel" control. I am not sure if there are other controls that will do this yet. For now I just plan on re-writing the code to not use a link label on the user control though and see how well that goes.
I'm working on a report in Visual Studio/Crystal Reports (2005). Whenever the grouping expert is accessed, the development environment locks up. It happens both when I try to open it directly, and when trying to use the design expert for a new report.
I've done many Crystal reports before with out this trouble. The lockup occurs when I revisit an existing report.
I have no idea how to find this error.
The cause turned out to be that the Expert dialog box had been moved to a second screen on a previous occasion. Once I discovered that, it was easy to move it back into view. (Alt-Space, choose Move, move it with arrow keys.)
I found the solution on a Microsoft Q/A site using Bing. Not surprisingly, I find Bing has better coverage of MS data than Google.
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.