I've got a Windows form with a ZedGraphControl, and for some reason whenever I rebuild it in Visual Studio while the gui builder is open, the control randomly resizes itself & changes its position. Here's a screen capture showing the behavior:
http://screencast.com/t/WxrLngp1VLf
*If I rebuild it a second time immediately after, it moves & resizes once again (in other words, it moves over & grows each and every time I build).
*I am not touching this control anywhere in my code; I just dropped it in the dialog and rebuilt.
*It behaves the same way in VS2008 and VS2013.
*If the gui builder is not opened when I build, it always remains as it should.
*I tried adding it within a panel (in case it was doing something weird based on properties of the container), but it behaves the same.
I'm totally stumped, and this makes it very cumbersome to work on the dialog - anytime I have to build I have to close the gui builder, build, then reopen it (otherwise, I have to keep manually moving the graph control back to where it was supposed to be)...
...Figured it out about 15 minutes after posting (d'oh!). The solution was to change the parent form's AutoScaleMode from None to Dpi. Looks like a bug in ZedGraph!
Related
I'm developing in Winforms with a .NET 4 profile in Visual Studio 2010 at Windows' 100% scaling (96dpi) on Windows 10.
As per the advice from this highly rated answer, I set dpiAware to true in the app.manifest file, set the AutoScaleMode of the main Form to Font, and since I have splitContainers in the Form, but they very unfortunately don't have an AutoScaleMode property in the Wysiwyg Designer, I also have to add these lines to the Designer.cs file:
*.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
*.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
This ensures that if the user happens to use Windows in 125%, 150% or even other scaling modes, then the GUI will resize properly, without some components being too small or too big.
Unfortunately, as per the advice of the aforementioned link: "Only the controls in the Controls lists when ResumeLayout at the end of InitializeComponent is called will be auto-scaled", which means I need to put the above two lines in the Designer.cs file. I can't simply put them later in the Form Load event.
Unfortunately, this means that whenever I update or move about a widget/button/label in the Wysiwyg editor, the Designer.cs file is automatically recreated, and I lose my two lines of code above. So I have to keep remembering to put them back in every time I update the GUI in the Wysiwyg editor.
The link also supplies a potential solution to avoid this ugliness by partially avoiding the use of the Wysiwyg editor, and instead creating the splitContainers programmatically in the Load event. I quote: "if you dynamically add controls, then you need to SuspendLayout(); AutoScaleDimensions = new SizeF(6F, 13F); AutoScaleMode = AutoScaleMode.Font; ResumeLayout(); on that control before you add it in".
The problem there is that I have a ton of splitContainer code to move over (such as objects being added to the splitContainers), and it will ruin the look of the Wysiwyg editor (I want to see my splitContainers thank-you-very-much as they are a crucial part of the GUI and have many elements/widgets inside that I also want to see when designing!).
My question is if I can get the best of both worlds: Keep the look of the splitContainers and contents in the Wysiwyg editor, while keeping the functionality of proper scaling by utilizing the two lines of code above (*.AutoScaleMode = ... and *.AutoScaleDimensions = ...) which seemingly must be in the Designer.cs file before *.ResumeLayout() is called.
I'm looking at improving developer experience when running graphics tests which spawn short-lived windows "like crazy". The windows need to be physically there, as otherwise data readback fails (i.e. the window cannot be hidden)
Needless to say, windows popping up at high frequency is unpleasant. I set out with the goal of finding a way to tell XCreateWindow to "create the window in the background", "not to steal focus" or something like that to no avail. The closest thing I could find is calling XSetInputFocus post-creation. Other than the fact that I couldn't make it work, I don't expect setting input focus to fully solve the issue anyway (as the windows would still pop up, just not without input focus, right?).
How is this done in X11?
P.S. The update notification on Ubuntu starts without popping to front, so this must be a possibility.
In the past I've tried and admitedly failed doing what you want to do. Nevertheless I've found a few "close-enough"-solutions that may be of interest.
XCreatePixmap might work out, but in my case didn't have a pixmap with desired properties (multisampling) so it "out the window" (haha)
To prevent some level of spaming you might be able to set XCreateWindow parent to a an exisiting window other than root, large enough to hold your tests and moved outside display. The parent window need be created, moved outside display and un-focused, but at least every window creation won't steal focus (I think) and spam on display.
Or you figure out a way to create additional displays, maybe using Xvbf. Didn't have admin access to corp dev env so didn't bother trying to install/configure, in addition to other obstacles, but it might just work for you.
It happened again. My test data is not shown any more. I see only class and property names. Restarting does not help this time. Retracing neither.
I've been rewriting my whole project since that happened.
Now I tried to use Test Data class to address it from custom user controls so it would look like:
...d:DataContext="{Binding Source={DynamicResource TestData}, Path=Emploee}"...
//in resources
<main:TestData x:Key="TestData"/>
Not like it was previously:
...d:DataContext="{DynamicResource TestEmploee}"...
//in resources:
<shar:PVEmploee x:Key="TestEmploee" Name="Alpha" Surname="Omega" Phone="77777777" PVProfession="{DynamicResource TestProfession}"/>
<shar:PVProfession x:Key="TestProfession" Name="Some obnoxeously long profession name"/>
And right after those changes in this control (I've done it previously few times already to other controls, I've copied from previous project version) the designer crashed. Now I see
this ridiculousness, instead of test data
I am frustrated. Am I supposed to restart it again? Or there could be some way to fix it.
Answer to almost not realated question Actually worked well (the question was - how to crash a Designer =D ). If I kill designer in Task Manager, and click 2nd option in Studio. The Designer loads pretty well in a right way. All my Test Data right there. Or I found later that I can click small document icon on designer bottom to reload it with or without user code.
After a few such resets it started behaving. Marvelous!
I change the text property of labels on a windows form. The form displays the correct new labels when displayed in the VS 2010 forms designer. I also change the color of the font.
When I run the program, the window displays the old text values instead of the new text values. The form displays the new font color on the labels.
There seems to be no occurrences of the old text value in the source code. Where is the old text value still hiding?
I clean the solution and rebuild it, but nothing changes.
A colleague observed that this is an artifact of converting projects from VS2005 to vs2008 to VS2010 and suggested a "brute force" corrective measure.
It actually worked.
1) Create a new blank form in the project.
2) In the original form, using the forms designer "Edit" menu, use the "select all" and "copy" actions. This copies all forms objects into the clipboard.
3) Paste the clipboard into the blank form.
4) Copy (most of) the program code from the old form into the new form, excluding anything generated by the forms designer.
5) Delete the old form from the project. Make changes as necessary to use the new form
Not very elegant, but good for meeting a deadline.
Thank you J.H!
Epilog:
"Brian" and "Blogbeard" both had the right direction in suggesting a hidden resource file.
Early in the execution of the code lay a method call to an obscure subsystem that no one knew anything about. That subsystem turned out to be a defunct language translation module which was supposed to translate all of the labels in a form from a native language to a target language.
It was configured to keep the original labels and their translations in a file outside the scope of the IDE. Changes in the form itself were completely ignored if the translator found the label name in its file.
Moving the form contents to another package effectively disabled the translator.
The elegant solution turned out to a three-line change that removed the method call to the translator. (it was no longer required in the application)
I am experiencing some very strange behavior with Blend:
Since weeks i am working an a project where I use Blend 4 and Visual Studio 2010 simultaneously. I've never experienced problems with one of these programs or with their co-existence. Work proceeds fine.
But a few minutes ago - from one boot of the computer to the next - Blend seems to have a serious problem:
From now on I am not able alter any value anywhere in my project. I can't create new Controls on a plain surface as well delete existing ones. If i try to alter some attribute of some existing control, the width of an existing button for example nothing happens:
Drag and Drop with the mouse results in nothing more than a slight flickering of the control which looks like if it is fighting against my modification to retain its current value. Regardless what manipulation I apply with the mouse the control stays untouched neither does any value in the properties-panel of Blend change.
It feels as if my project is in read-only mode or locked somehow.
But now comes the frustrating fact: When I apply the modifications described above nothing changes BUT the corresponding XAML code does! Enlarging the width of a button with the mouse doesn't show any effect at the control itself or in the properties pane but the XAML attribute width is changing as I move the mouse ?!
Did anybody also experience this behavior before ? Does anyone has some suggestions ? Maybe the solution is very obvious and just made a fool of myself but I got really stuck with that problem - so any help or suggestions are very much appreciated ... Thanks in advance !
EDIT: It really seems to be a Blend problem because when I open the project in Visual Studio everything is working as it should ...
Are you certain that there is not a control sitting on top of the others?
Alternatively, are your other controls in a panel (perhaps a grid) that has it's visibility set in a trigger? If so, Visual Studio displays controls visibility a little differently than Blend does. Blend attempts to get the property to which you bound your visibility during design time, whereas Visual Studio seems to display the item so long as you have visibility initially set to visible.
Can we see some code to make sure?