ASP.NET and VERY buggy VS.NET 2003

[Elliot Rodriguez]

WinXP Pro

Let me preface this by saying I have developed with the .NET IDE since its
release, and I consider myself reasonably savvy with it.

I have a medium sized form with about 120 controls - 60 labels and the rest
are DropDownLists and TextBoxes. Almost every TextBox or DropDownList is
placed in a Panel control whos visibility property is changed based on
postbacks from another DropDownList (basically its a form that builds up
based on DDL selections).

The first buggy thing I notice that seems to be particular to this project
(at least this page) is that my DropDownLists often seem to lose their
bindings to the SelectedIndexChanged event. The code is present for the
wiring, yet when I run the project, my postbacks do not fire. I have to
double click the DropDownList (which takes me to code that I have already
written), and only then does the postback coding work.

The second thing concerns my mouse - there are moments when my mouse will
not move beyond an imaginary boundary within the designer. Usually the
boundary is defined by the same width and height attributes as the table or
panel I'm working in. It just suddenly decides it wants to stay in that
area. Only if I take VS.NET out of focus and return to it does the mouse
work properly. Its almost as if theres something weird going on with windows
system events, but who knows.

While these 2 items only happen within this project I'm working on, another
bug I've found is related to my builds - often VS.NET will report a build
error, but nothing shows up in my task list. If I continue to run the
project, it runs without throwing any runtime errors; it simply thinks that
something is wrong with the build but reports nothing.

Wondering if anyone has experienced the same and has a possible workaround.
My form development is taking much longer than it should because its just
behaving oddly.

 

[Terry Burns]

Firstly, I dont think a form with 120 controls/60 Labels on it is a medium
sized form. Although ASP.NET should be able to handle it, you may want to
consider re-thinking your design and perhaps using a multi part process with
more than one form ?

I have experienced similar things ( not the mouse bit ) when designing
asp.net apps before and almost without exception it has ended up being a
logic or flow error which causes the apparently 'odd' behaviour, seemingly
lost bindings etc.

This is probably not much in the way of direct help, but maybe it could give
you some point of reference. In summary, my only other offering would be to
suggest you map out very thoroughly the events which take place in the
firing order on a large sheet of paper and try and work out where you could
be going wrong ( if thats the case ).

HTH

 

[Guest]

Elliot,

I am experiencing the first two problems which you are facing now and I
never encountered the last bug.

I hope that Microsoft will release a patch for VS 2003 or would they want us
to upgrade to VS 2005 ?

 

[Elliot Rodriguez]

The form's design cannot be changed. Its meant to be a dynamic form that
builds on previously selected options, and the user must stay on the same
page.

I have considered breaking up the page using IFRAMEs, but this is a kludge
at best.

Rendering this form should not be terribly taxing. While there are 120
(total) controls, and I can eliminate 60 by not using labels (which I do
because I can access them by name in the DDL postbacks and change text
dynamically), 60 dropdownlists with perhaps at most 5 ListItems to each
(with minimum DB IO) should be a piece of cake.

I think its more a problem with the IDE than anything.

 

[Erik Funkenbusch]

I have a medium sized form with about 120 controls - 60 labels and the rest
are DropDownLists and TextBoxes. Almost every TextBox or DropDownList is
placed in a Panel control whos visibility property is changed based on
postbacks from another DropDownList (basically its a form that builds up
based on DDL selections).

Frankly, I didn't read most of your message because this right here is the
source of your problem. In my opinion, the GUI designer is useful for
small to medium and quick and dirty pages. If you start designing huge
monstrosities, you really should invest in building an infrastructure to
support your project(s).

Large scale projects require a lot more work than small-mediaum RAD stuff.
I think you're just out of your mind to put 120 controls on a form using
the GUI designer.

 

[Erik Funkenbusch]

The form's design cannot be changed. Its meant to be a dynamic form that
builds on previously selected options, and the user must stay on the same
page.

A design can always be changed. I think you're only thinking in a RAD
mentality. You might want to understand the bindings the GUI is doing and
why it's doing what it's doing (or not doing what you think it should be).

You should always strive to understand frameworks at a deeper level than a
GUI gives you.

 

[Terry Burns]

I have delivered several large asp.net applications, so I think I can talk
with some experience here. The IDE will slow down considerably when you load
it up with huge numbers of controls but it ususally manages to cope. I have
noticed that sometimes it can get a little lost with the positioning of
controls, but everything still generally does still work.

If I have to design a form which has as many controls on it as yours does,
then I change the design, not because I dont think the ide cant actually
handle the number of controls but because I cant keep track of the number of
possible things which can go wrong coupled with the IDE slow down, so I
normally alter the design to compensate.

The other problem with designing forms with large numbers of control is that
they tend to be 'Very' time consuming in setting up and the time taken to
design a form with double the controls of another seems to obey some law
which makes the time required three or four times as long. Additionally,
users do not like working with forms which are crammed with controls because
it's confusing to look at and too easy to miss an option, and this can
happen with as little as 30 controls.

One option you may want to consider is the use of user controls, these as I
am sure you are aware logically grouped controls and can be loaded
dynamically on the page. This may or may not help depending on your design.

But hey, feel free to press on with your endeavour; I wish you the best of
luck as I think you are going to need it if you want to continue beating the
thing with lots of your time.

;-D

 

[Alec MacLean]

I've also found that VS2003 does have IDE problems. Frequently I notice
that controls with an event handler will lose the event binding. This
manifests as the "Handles myControl.<event>" statement being cut off the end
of the procedure definition. It's easy enough to add it back in, but it is
very frustrating to need to do so.

This seems to happen most frequently on forms that are using panels that are
not visible by default, by are revealed after specific user action.

My experience of this would seem to corroborate with Elliot's.

I haven't had the problem with the mouse though. Perhaps this is partially
related to the mouse driver variation on your dev PC? I use an MS
IntelliMouse with the IntelliPoint 4.12 driver set.

Al

 

[Guest]

Elliot,
Unfortunately in 1.1 the delegate hookups
(e.g., mycontrol.Click+=new .... etc) get bombed especially when switching
from design view to source view. The action of double-clicking on a control
on the IDE designer surface is actually putting this back in (in addition to
wiring in the templace event-handler method). You might want to experiment
with setting the autoeventwireup directive to false and putting these in by
yourself.

In the ASP.NET 2.0 model this is handled much differently with partial
classes, and there is less chance of this kind of problem.
Peter

 

[Terry Burns]

Hi Peter,

I have never lost a handler this way. Maybe I'm just lucky ? BTW,
AutoEventWireup is set to "false" by default, if it wasnt he would have
even more problems.

In the ASP.NET 2.0 model this is handled much differently with partial
classes, and there is less chance of this kind of problem.
Peter

Just curious here; How does having partial classes prevent this alleged bug
?