I have a C#.NET winforms project, and some controls are moving in design view whenever I build the project. Its only some of the controls (a panel with a label and datagridview in it, a button, a link button and a label) are all moving up on each build.
Has anyone seen this before or know how to fix it?
I think it is because of the AutoScaleDimensions. My guess is that your form was originally created on another machine.
Per MSDN.
"The AutoScaleDimensions property represents the DPI or font setting
of the screen that the control was scaled to or designed for.
Specifically, at design time this property will be set by the Windows
Forms designer to the value your monitor is currently using. Then,
when the form loads at run time, if the CurrentAutoScaleDimensions
property is different from the AutoScaleDimensions, the
PerformAutoScale method will be called to perform scaling of the
control and all of its children. Afterwards, AutoScaleDimensions will
be updated to reflect the new scaling size."
My guess is that for odd some reason when you build you project property (maybe some others) gets adjusted, but not on design time.
I think about few possible reasons:
You work on multiple monitors and/or there is some odd stuff with your adapter.
There is some problem with auto-generated designer file. Maybe it
edited manually somehow.
To fix I propose to do something I would do:
Recreate form from scratch if possible, by copy-pasting bits
one-by-one.
If not take some merging tool and insert fresh form
properties.
Also here is another interesting question on AutoScaleDimentions.
Related
For some reason Visual Studio winforms designer time to time applies dull changes to form designer files and respective resx.
Most annoying so far:
changes to order of controls declarations/initialization
changes to some control sizes (most notably menu items widths)
changes to serialized images embedded into resources (...wait, what???)
Those changes doesn't affect form/user control functionality or it look, but they create lot of noise in source control, making merges almost impossible, or require error prone manual fixing to eliminate all changes that actually change noting, just until next change to designer.
Any ideas how to prevent studio from it?
Please try to have your control locked using the right button, then select "Lock controls" on your Form/UserControl.
Unfortunately, there is no way to separate "useful" changes in generated code from "pollution" that come from a control designer bug or internal working.
If the lock control feature does not work for whatever reasons, there is not much that we can do, except those horrible hacks:
Once your form is created and finished, move your generated code (InitializeComponent method and declarations) out of the .designer.cs. Visual Studio will not touch it anymore. The drawback is that you will no longer have visual support.
Having the .designer.cs file flagged as read only will prevent Visual Studio attempting to change it. It might cause Visual Studio control designer hiccups sometimes, but it will leave your .designer.cs intact.
There is another way that consist in not using the designer at all. This leads to a new way to embrace winforms programming, because you will provide the code to initialize controls with their properties and events.
It is not as huge and ugly as it seems to be: using reusable patterns and OO features could be very pleasant, and some well aligned methods calls are better that some horrible code hidden in a .designer.cs file.
Of course there will be no visual support, but you can cheat it by adding your control to an empty container in design mode to see how it looks like.
As far as I understand, you have edited .designer.cs file. From one point it is OK, I guess we all do that. However, there is clearly notification there 'file is auto-generated, do not change it'. So Visual Studio puts you a warning that if you edit it things may not go always well. It is like that by design. And while those auto-changes might not make trouble to your app, they do sometimes (e.g. setting width and height to the control that should change its width and height contextually, and that is always necessary if you have multi-language app).
So if you don't like garbage, you don't use designer, because it creates garbage, that's how it works. Or you start with it and at some point decide to never open it again and then do your cleaning.
Or you go WPF, it meets your requirements, and it is about time to make WinForms legacy, at some point support for it will surely end.
I have a WPF application that renders input forms based on form-configurations saved in a database.
The forms have many controls (100+) and most of these controls are derived from a TextBox-control. On some machines (fast Hardware, Win7 32Bit, also some elder, Windows XP 32Bit), after entering data to a lot of these forms, input performance goes down. Every keystroke gets a delay of some milliseconds and the only solution to resolve this is to close the application and restart it.
My derived control overrides the metadata of the DefaultStyleKeyProperty to set a custom template.
I'm currently reasearching the app in SciTech memory profiler, but maybe someone has already experienced a similar problem with derived TextBoxes and can give me a hint and spare me some more hours/days investigating the problem?
Update
Look also here
It sounds like you may have something stopping the controls on the "used forms" being GCed.
Firstly opening and use as many forms as possible looking at the windows task manager to see if you memory usage is going up – if it is not there is no point looking for memory leeks
Check you are removing all events handlers you forms/controls have put on any long lived objects.
Check that any objects you databind to implement INotifyPropertyChanged, see KB938416
I have in the past had good results using the Red Gate memory profiler.
You don’t need to have controls created that the user can’t see, 100+ controls will have a cost.
Can you use something list a list control in virtual mode, so your TextBox controls are only created when visible.
I'm doing a WPF application, using Blend4 and VS2010 for editing the XAML files.
One of the most anoying things of this is the process of making small changes and see them in action. As the data in the View is populated from a ViewModel and a Model via Bindings, the things you see in the Blend designer aren't the same you get when you run your application. You need to recompile and "re-run" your application every time you make a change, no matter if it was only to change a pixel in the margin of some element.
I want to know if there is any way to perform quick changes in your XAML and watch them in the real interface.
Like in the Websites, the idea is similar to make a change in the HTML and then press F5 to see the changes.
Maybe you can run "part" of your application to bind the view data to the model, and then change only the "view code" of the xaml.
Do you know if this is possible?
Thanks!
Whether using Blend or Visual Studio, the key to rapid design of MVVM user interfaces is sample data. You can use the same view model at design-time as you you do at run time as long as the data is doesn't access services.
Whether you are using MVVM Light or not, you can use its technique to allow your view-model to detect design time and return different data. You can also read Laurent Bugnion's ideas on sample data here:
WPF: Simulating data in design mode in Microsoft Expression Blend
We have a legacy application that utilizes VB6, the Flash ActiveX control, and Flash content to display animated movies to users. For plenty of reasons we're looking to migrate away from this. I'm hoping someone out there can answer a few questions about WPF so that we can make a determination about how best to move forward.
First, a little about our current architecture and needs. The Flash content is set up as separate SWF files, where each individual SWF represents a training module with animated content. We have hundreds of these modules. Users run this software in a disconnected fashion where their local machine may or may not have ALL of these SWF files. The current application gives the user the option of downloading the SWF modules as they're needed.
Here's how we're thinking about setting up a new solution using WPF and Blend. We've written a WPF host application that can dynamically show Blend content based on button presses or whatever. And we've created a few test modules in Blend as WPF custom controls. But there are three nagging questions:
Right now we have the custom controls within the main WPF solution, but we need to make these disconnected. I've read several things about using Application.LoadComponent but I don't know if that will work for our solution.
Each of the Blend custom controls contains one or more storyboards that control the animation. As soon as I add one of the custom controls to a container in the WPF app, ALL of the storyboards automatically start "playing". How can I programatically make it so that I start/stop certain storyboards as needed?
Let's say I want to change a text label in one of the custom controls. If we're dynamically loading the custom control, how would I access one of the text labels to make such a change?
Any tips would be greatly appreciated. Loving WPF so far and hoping we can make this work and say goodbye to Flash forever!!!
There is Manage Extensibility Framework, that is a standard approach for dynamic modules.
Anyway, I haven't used it, so I would answer the questions in other way:
1) No, LoadComponent is ised for xaml files, whereas custom control consist of code and xaml. I mean, the custom control that you can add using Add->New Item->Custom Control(WPF). So you should do something like this, with reflection and ContentControl:
Assembly asm = Assembly.LoadFile(#"C:\SomeLibrary.dll");
Type type = asm.GetType("SomeNamespace.SomeControl");
var control = Activator.CreateInstance(type) as Control;
this.myContentControl.Content = control;
2) It isn't fact. You can put the storyboards into Control.Resources and launch them manually.
((Storyboard)control.Resources["myStoryboard"]).Begin(control);
3)
control.FindName("anyname") as TextBlock;
I've created a series of usercontrols. Dragged one of the controls to the main form. It shows OK. Went back and made a change to the design of the user control. Rebuilt project. Cleaned project. manually removed all project binaries including the obj folder. Change still doesn't show on the usercontrol hosted on the main form. Dragging a new instance of the control from the tool box only shows the old version of the control.
Completely removed the controls from the toolbox and adding them again fixed the problem, but surely I don't have to do this everytime I make a change? All user controls are in the same assembly as the main form. Tool>Options>Windows Forms Designer>Auto toolbox Populate is set to true. Any ideas most appreciated. Thx
Do not add the control to the toolbox yourself. This puts a copy of the assembly in a private directory. Yes, this copy does not get updated automatically, you get the old control.
Rely on the "Auto toolbox populate" setting. It automatically adds any controls you have in your loaded project(s) to the toolbox. The added controls are at the top of the toolbox.
I agree with answer 1 that that is what is supposed to happen, and often does. But it doesn't always work and will work partially sometimes.
For example my current Solution.
Project 1 namespace ToolsTester - This is just a temporary form to test the view tools in the 2nd project.
Project 2 namespace UltimateFileFinder - This has three views.
The first 2 views (user controls) UltFilesView and UltSlideShow appeared as usual on the toolbar so I could drag them onto ToolsTester to try them out.
Then I added another user control UltPanel, this will not go onto the toolbox. Though it compiles without errors.
I have come across this problem a few times, sometimes removing and reasserting the reference fixes it. Other times I would have to remove the test project and create a new one.
I tested Visual Studio (full version) before release and this was one of the areas I reported back, so the problem was known pre-release.
This project I am on now I know that I will need to remove the test project and create a new one, in this case the tester is only a few simple caller and event responses, that is not always the case, there are times when the tester project can be quite complex because it is mimicing the target that the tools will be part of.