When i write my programs in Visual Studio (2008), they run perfeclty at my computer: program's objects are placed as i did it in designer. But when i run programs on other computers, some objects are placed wrong by few pixels: they touch other object. I suppose it is due to my monitor's resolution (1680x1050). I find that I can use TableLayoutPanel. Any other ideas to solve my problem? Thank you.
Why don't you set the size of your application's window to a desire resolution and see how it is rendered. This should render the GUI as if the application was running in those resolutions.
Another thing you may check is for how the size of the columns/rows on TableLayoutPanel are defined. You can set their size as a relative or absolute size. If you set it to an absolute size the objects should appear always on the same place.
I suggest you write a test application with as few controls possible where you can reproduce the issue.
Then, come back here to SO and describe exactly what situation you have
which controls show that behaviour?
does it only occur with TableLayoutPanel, or with other Panels, or without any Panel?
does it only occur when the user changes the form's size?
Please post some code or screenshots.
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 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.
I am currently working on WPF touch-screen application. I am developing it on Windows XP machine. I have tested it on this machine and it works perfectly fine. But when I deploy it to Windows Embedded machine I start to get strange behaviour: all pop up messages, drop down list, context menus appear behind the main window.
I am also setting the focus on my main window, when application loads, to enable context menu on the main screen.
Also my main window's AllowTransparency is set to true, (I have seen people had similar issues when having set to AllowTransparency). And also this didn't happen in the previous release.
Edit: The issues has gone after several compilations, I was unable to reproduce it, but I am still trying.
I also think it has to be something related to graphic driver, as it happens on one windows XP machine, but not on another (hardware is different, one run XP embedded 2nd XP professional).
Any idea why this is happening?
Have you tried forcing the ZIndex of the elements to that they are higher than the main window?
This MSDN blog post describes it's use - but the important part might be:
The first set of Rectangle objects uses the default z-ordering rendering of objects, which is based on the position of the child object in the Canvas collection
So if the order the objects are created has changed (for whatever reason) you might see this behaviour.
Explicitly setting the ZIndex will confirm or deny this.
Is it possible to stop the Unloaded, OnApplyTemplate and OnTemplateChanged from triggering when we change the default font size in Windows XP?
It's been causing us some problems and we haven't figured out a good way to handle it. If you know what other events get triggered under this situation, it would help us a lot too.
Thanks!
The short answer is no. Many of the theme-dependent properties are set up in WPF as dynamic resources, meaning that templates get re-applied, etc. so that WPF apps behave well when those theme-based resources are modified.
Maybe you should re-post your question looking for specific solutions for what's breaking when the user changes theme-based properties.
I am relatively new in the WPF world and one thing I immediately noticed is how laggy the window content is drawn when you resize a window. For example if you have scrollbars at the window edges those scrollbars will be partly hidden while shrinking and have space between them and the window border when enlarging.
This even happens with an empty WPF project created in Visual Studio. What's even worse is that it also happens with the background and you can see stuff behind the window (other windows, desktop wallpaper, etc.) leak through when enlarging.
At first I thought that it's an ugly limitation of WPF seeing that native or WinForms applications resize just fine (if written properly). But when I look at Expression Blend the window background stays opaque (though the window content still lags behind). What do they do to prevent described problem and are there any ways to improve resizing to more approximate native/WinForm GUIs?
The reason of lags is nicely explained here
Are you running Vista without SP1 ? From what I have read, this was a common issue that is supposed have been fixed..
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/3960d6a6-e873-455c-9ddc-1e2dd32e090b/
I'm not seeing this behavior, myself. I develop on vista x64 sp1 and/or a virtual pc running xp x32 sp3. Wpf uses directx, could it be your video card/machine? Try running your app on a diff machine and see if you have the same results.
I have the same issue with the interface lagging while resizing. I suspect that the reason for the lag is it is resizing the underlying frame buffers in direct X which is never particularly fast. I am not sure what you can do about it though.
I've been looking for information on this issue as well. I just thought it was a windows "feature" that some intrepid microsoft programmer thought would be cool. I was hoping to be able to turn it off so that window resizes would actually follow my mouse, instead of lagging and then overshooting. Grr.