ASP.NET and VERY buggy VS.NET 2003

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.

Elliot Rodriguez

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

--
Terry Burns
http://TrainingOn.net

"Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
news:...
> 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

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" wrote:

> 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.
>
>
>

=?Utf-8?B?RGlmZmlkZW50?=

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.

"Terry Burns" <> wrote in message
news:...
> 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
>
> --
> Terry Burns
> http://TrainingOn.net
>
> "Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
> news:...
>> 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.
>>
>
>

Elliot Rodriguez

On Fri, 3 Feb 2006 15:09:12 -0500, Elliot Rodriguez wrote:

> 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

On Fri, 3 Feb 2006 15:38:28 -0500, Elliot Rodriguez wrote:

> 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.

Erik Funkenbusch

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

--
Terry Burns
http://TrainingOn.net


"Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
news:...
> 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.
>
> "Terry Burns" <> wrote in message
> news:...
>> 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
>>
>> --
>> Terry Burns
>> http://TrainingOn.net
>>
>> "Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
>> news:...
>>> 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

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



"Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
news:...
> 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.
>
> "Terry Burns" <> wrote in message
> news:...
>> 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
>>
>> --
>> Terry Burns
>> http://TrainingOn.net
>>
>> "Elliot Rodriguez" <elliotrodriguezatgeemaildotcom> wrote in message
>> news:...
>>> 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.
>>>
>>
>>
>
>

Alec MacLean

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

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com




"Elliot Rodriguez" wrote:

> 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.
>
>
>

=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=

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
?


--
Terry Burns
http://TrainingOn.net
"Peter Bromberg [C# MVP]" <> wrote in message
news:0FB16511-D423-494E-93DC-...
> 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
>
> --
> Co-founder, Eggheadcafe.com developer portal:
> http://www.eggheadcafe.com
> UnBlog:
> http://petesbloggerama.blogspot.com
>
>
>
>
> "Elliot Rodriguez" wrote:
>
>> 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