BUG: WinForm designer in C#...

  • Thread starter Thread starter anonymouse
  • Start date Start date
A

anonymouse

We have a number of machiens with VS.NET 2003 installed and on every
machine, the forms in the designer are comming out different sizes and when
we build and run the app (without code changes) they appear different on
every machine. Why? We disabled auto scaling of fonts we locked the form
yet nothing helps.

Any ideas why this is happening and how to fix it?
 
This is kinda a dumb question, but are all your machines running at the same
video resolution?
Maybe check InitializeComponent() to ensure the window size is being set.
 
Its causing problems on the code checkins also, its somehow resizing the
form. when I build its appearing different on others machines. I was told
its a known problem.
 
* "anonymouse said:
Its causing problems on the code checkins also, its somehow resizing the
form. when I build its appearing different on others machines. I was told
its a known problem.
Click to expand...

The problem can occur if the form is edited on computers with different
number of dpis. VS.NET will change the form's code automatically...
 
Ok, how can i disable this as its causing havoc in a developement
environment between laptops, desktops XP, 2000 etc.

Its literally causing havoc on checkins .
 
This happens even if the form .Locked design property is = true. I see this
as a BUG nothing more nothing less than a badly designed feature.

There is no benifit to this, its a problem maker. We even set .AutoScale =
false , doesnt help.

This is a dumbass feature. If we set the size, it should stay at that size,
not whilly nilly resize itself. This has got to rank as one of the most
stupidest features Ive ever seen.


anonymouse said:
Ok, how can i disable this as its causing havoc in a developement
environment between laptops, desktops XP, 2000 etc.

Its literally causing havoc on checkins .
Click to expand...
 
Instead of saying "it changes things", could you post snippets of the exact
lines of InitializeComponent() that are getting changed, and show us a
"before" and "after" on those lines? I might be able to make suggestions if
I knew what the problem was. (Or I might not -- there's always that
possibility too.)

Also, does the problem occur only when the file was last checked in by a
Win2k-based developer and is then opened by a WinXP-based developer (or vice
versa)? Or does it occur even if the file was last modified on one Win2k
machine and is later checked out on another Win2k machine?
 
Whats I saw also happening on one machine was the form becomming wider then
after a few restarts it was back to normal. Odd behaviour indeed.

Thats the basic reason I hate wizards n designers, I just dont have faith in
them.

anonymouse said:
Ill make a diff of the .cs file when I get back to the machines.



Joe White said:
Instead of saying "it changes things", could you post snippets of the exact
lines of InitializeComponent() that are getting changed, and show us a
"before" and "after" on those lines? I might be able to make
Click to expand...
suggestions
Click to expand...
 
* "Joe White said:
Instead of saying "it changes things", could you post snippets of the exact
lines of InitializeComponent() that are getting changed, and show us a
"before" and "after" on those lines? I might be able to make suggestions if
I knew what the problem was. (Or I might not -- there's always that
possibility too.)

Also, does the problem occur only when the file was last checked in by a
Win2k-based developer and is then opened by a WinXP-based developer (or vice
versa)? Or does it occur even if the file was last modified on one Win2k
machine and is later checked out on another Win2k machine?
Click to expand...

The designer will change the 'AutoScaleBaseSize' property when opening
the project on a machine with different number of dpis (in VS.NET 2002).
 
I suspect that AutoScaleBaseSize is ignored *at runtime* if AutoScale is
false, but that *at design time* it's written to InitializeComponent()
regardless of the AutoScale setting. This would make some sense, as it
would make sure things would work correctly in case you later decided to
change AutoScale back to true.

But wouldn't AutoScaleBaseSize only change if some of your developers are
running in Large Fonts mode and others are not? I would think you'd have
noticed already if that was the case -- if different developers are running
different dpis, then of course you'd have lots of diffs every time you check
in.

Again, it would be helpful to know exactly what's changing when you check in
from different machines. Otherwise, we're just guessing.
 
* "Joe White said:
But wouldn't AutoScaleBaseSize only change if some of your developers are
running in Large Fonts mode and others are not? I would think you'd have
noticed already if that was the case -- if different developers are running
different dpis, then of course you'd have lots of diffs every time you check
in.
Click to expand...

That's the problem. If one developer works on a notebook with large
fonts enabled, the forms will show wrong on a normal pc with normal fonts.
 
That's the problem. If one developer works on a notebook with large
fonts enabled, the forms will show wrong on a normal pc with normal fonts.
Click to expand...

Theoretically, if your app is designed to support scaling at all, it should
work perfectly. If you can't handle designing in large fonts and running in
small fonts, then you certainly couldn't handle the probably-more-common
case of developing in small fonts and running in large. But if you *can*
handle scaling (going both ways), then you would see a lot of diffs when
going from a small-fonts development PC to a large-fonts one, but no actual
change in runtime behavior. Theoretically.

But I know very little about .NET's form-scaling features, so I couldn't
even begin to guess what settings it would take to make it work this way.
Maybe the default settings take care of it; I don't know.
 
So, any suggestions on how to solve this?

Its causing problems this "feature". Never seen this on
before on any designer.


Its definately a problem maker rather than a problem
solver for us.

How can we override this behaviour because .AutoScale =
false sure isnt doing it or rather, its a half assed
solution because its only affecting runtime and not design
time.
 
Ok I have the form in front of me, the form is LOCKED in
design time, the autoscale = false and I did a diff after
a build and closing VS.NET I get NO DIFFERENCES!!
probably because the form is locked, but when I build it,
the form is obviously wider if I compare them, its so much
wider, its unbelievable and when I run this exe on other
machines, its nuffed and way off size.

Its a real pain in the gonads. What would be the best way
to handle this "feature" because we need a fixed form size
and obviously we are not getting this in .NET.
 
If large fonts isnt enabled on the laptop

Could it be the slight differences in the fonts on diff
installs?

Microsoft Sans Serif, 8.25pt is what I have currently as
the default which I presume is standard on most VS.NET
installs.

Problems problems problems with this feature, my guess is
MS had everybody use the same GHOST image for testers and
they never seen this issue. It maybe classed as a
feature, but forus its a freakure. Doesnt work in my view
plain and simple.
 
If large fonts isnt enabled on the laptop
Could it be the slight differences in the fonts on diff
installs?

Microsoft Sans Serif, 8.25pt is what I have currently as
the default which I presume is standard on most VS.NET
installs.
Click to expand...

That font setting is saved as part of the form, so different computers
shouldn't be changing it. But again, until the OP posts the diffs, there's
no way to tell what's causing the problem.
 
AutoScaleBaseSize which is slightly different. This is changing on
different machines and rendering the designer useless for us.
 
Back
Top