BUG: Designer breaks UI code

Hi,

We have a form designed in the VS designer in C# and everytime we build on
different machiens its chainging the .Location and .Size properties yet we
are not changing anything in this.

We have locked the form, we have set AutoScaleBaseSize and so on to false
and its still having a mind of its own.

Why can we not have STATIC form SIZES across machines?

Will this issue (bug by design = annoyance and costing time which is
money) be fixed?

Thanks.

[rollasoc]

Just to backup your idea a bit?

My latest project, explicitly forces the position of a panel to a specific
point on form loading and on file loading. Works fine under our test
setups, but the panel is moved to a different location on chinese and
japanese windows (regardless of operating system).

Not sure how to fix it.
<di********@discussion.microsoft.com> wrote in message
news:uh**************@TK2MSFTNGP11.phx.gbl...

Hi,

We have a form designed in the VS designer in C# and everytime we build on different machiens its chainging the .Location and .Size properties yet we
are not changing anything in this.

We have locked the form, we have set AutoScaleBaseSize and so on to false and its still having a mind of its own.

Why can we not have STATIC form SIZES across machines?

Will this issue (bug by design = annoyance and costing time which is
money) be fixed?

Thanks.

[Codemonkey]

I'm not sure if this is the same thing, but I've noticed sometimes that
controls move down the form slightly every time the designer is opened. I've
noticed this in VB as well as C# so I think it's a bug with the designer.
(It happens in both Visual Studio.net and Visual Studio.net 2003).

I think that if you leave the font of the form set to its default (MS Sans
Serif, 8pt Regular - I think), the problem stops happening. You can still
set the font property on all other controls without problem.

Hope this helps,

Trev.
<di********@discussion.microsoft.com> wrote in message
news:uh**************@TK2MSFTNGP11.phx.gbl...

Hi,

We have a form designed in the VS designer in C# and everytime we build on different machiens its chainging the .Location and .Size properties yet we
are not changing anything in this.

We have locked the form, we have set AutoScaleBaseSize and so on to false and its still having a mind of its own.

Why can we not have STATIC form SIZES across machines?

Will this issue (bug by design = annoyance and costing time which is
money) be fixed?

Thanks.

I think the designer is bipoloar (maybe it reflects the designer designer
:D)

Refactoring is a no no, static UI sizes across machines is a no no.

For anything serious, the designer is as useful as the resource editor,
useless.
"Codemonkey" <hu*********@hotmail.com> wrote in message
news:un**************@tk2msftngp13.phx.gbl...

I'm not sure if this is the same thing, but I've noticed sometimes that
controls move down the form slightly every time the designer is opened. I've noticed this in VB as well as C# so I think it's a bug with the designer.
(It happens in both Visual Studio.net and Visual Studio.net 2003).

I think that if you leave the font of the form set to its default (MS Sans
Serif, 8pt Regular - I think), the problem stops happening. You can still
set the font property on all other controls without problem.

Hope this helps,

Trev.
<di********@discussion.microsoft.com> wrote in message
news:uh**************@TK2MSFTNGP11.phx.gbl...

Hi,

We have a form designed in the VS designer in C# and everytime we build

on

different machiens its chainging the .Location and .Size properties yet

we are not changing anything in this.

We have locked the form, we have set AutoScaleBaseSize and so on to

false

and its still having a mind of its own.

Why can we not have STATIC form SIZES across machines?

Will this issue (bug by design = annoyance and costing time which is
money) be fixed?

Thanks.

If you do a diff on the .cs file you can see all the .Location and .Size
properties are all fuxored.

I had to spend 30 mins of wasted time going through and reverting those
properties in a huge InitializeComponent() method for the generated form.

The designer is a waste of space.

"rollasoc" <ho*****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

Just to backup your idea a bit?

My latest project, explicitly forces the position of a panel to a specific
point on form loading and on file loading. Works fine under our test
setups, but the panel is moved to a different location on chinese and
japanese windows (regardless of operating system).

Not sure how to fix it.
<di********@discussion.microsoft.com> wrote in message
news:uh**************@TK2MSFTNGP11.phx.gbl...

Hi,

We have a form designed in the VS designer in C# and everytime we build

on

different machiens its chainging the .Location and .Size properties yet

we are not changing anything in this.

We have locked the form, we have set AutoScaleBaseSize and so on to

false

and its still having a mind of its own.

Why can we not have STATIC form SIZES across machines?

Will this issue (bug by design = annoyance and costing time which is
money) be fixed?

Thanks.

[lover]

> For anything serious, the designer is as useful as the resource editor,

useless.

sad and 100% true

i think i have noticed a similar problem while opening inherited forms in
the designer. controls from the base class will have their location and
size properties changed arbitrarily. the workaround i have found is to edit
the code-behind -- even something as simple as removing and re-inserting a
line break -- then view the designer again and it will usually straighten
itself out.

Will this issue (bug by design = annoyance and costing time which is
money) be fixed?

a GUARDED look toward the future:
VS.Net 2002 had all these bugs;
VS.Net 2003 failed to fix them;
2004 will probably claim to fix them but fail;
by the time 2005 rolls around, there's probably a 50/50 chance of it working
right... (don't hold your breath)

(failing a fix, M$ might just regress to calling it 'Studio.Net' and leave
the 'visual' features in there but undocumented and unsupported. (other
than semantically, how different is this from the state of things right
now?))

on another note: would our lexicon even _contain_ the phrase 'bug by
design' if it wasn't for Micro$oft? =P

[harry_bosch]

"lover" <microsoft rulez!> wrote:

a GUARDED look toward the future:
VS.Net 2002 had all these bugs;
VS.Net 2003 failed to fix them;
2004 will probably claim to fix them but fail;
by the time 2005 rolls around, there's probably a 50/50 chance of it
working right... (don't hold your breath)

It's sad that Microsoft has put quality control on the back burner. VS.NET
2003 was a major disappointment with so many problems unaddressed (and new
ones added), and no service packs. I imagine that if the Visual
Studio problems got as much bad press as the security problems, they'd be
addressed, if only to "put out the fire". But since they don't, it seems MS
just isn't going to put any extra effort into addressing them.

BTW, I am convinced this is NOT a decision by the tech guys at Microsoft.
Most developers I've worked with hate the idea of having their bugs go out
to the public. (OTOH, maybe when the number of developers gets that large,
you lose any sense of individuality or responsibility). I suspect it's a
conscious marketing/management decision. After all, service packs and bug
fixes provide no income, and we'll all come back next year to upgrade
anyway, right? I can't come up with any other explanation that makes sense
(and believe me, I've pondered it many times, such as each time VS.NET
crashes or some other feature isn't working again).

--
harry

(Now Playing: Teilmenge 25A - Asmus Tietchens)