BUG: Designer breaks UI code

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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'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.
 
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.
 
For anything serious, the designer is as useful as the resource editor,
useless.
Click to expand...

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.

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
 
lover said:
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)
Click to expand...

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).
 
Back
Top