ASP.Net webforms and disabled controls
-
Well, maybe this isn't weird, and it's relating to ASP.Net Webforms so of no relevance to most of you anyway... but even though I've been using ASP.Net webforms for donkey's years, this is something I'd not realised / understood until just now. I have a form on which some of the fields may be disabled, depending on some rather complex logic. Some of the fields are disabled dependent on one of several statuses of a business object; others are disabled depending on a boolean flag that is available client-side. Some are dependent on both tests. I was finding that when posting back, ONE of the fields was "losing" it's value, and the underlying database was getting an empty value. (Fortunately auditing at the database level was tracking the changes in values, so in those cases it happened in the live system I was able to restore via the audit trail. I knew it would be useful!) Debugging in VS it was apparent that although both fields were disabled (and had the
disabled="disabled"attribute), one was empty right at the start of thepage_loadevent, whilst the other had the value expected. I know that disabled fields aren't posted back as part of the HTTP post, but ASP.Net was "restoring" the value (I understand through ViewState). What I couldn't figure out was why ASP.Net was restoring some disabled fields, but not others. Eventually I noticed that the one that had the expected value hadaspNetDisabledin the CSS class attribute client-side (as well as my own class name). Investigating showed that ASP.Net adds this attribute when the field is set to disabled at the server. It turns out that my code, which had evolved over years, had one set of "disabling" rules implemented server-side, by settingfield.Enabled = false... but the field that was returning blank, was getting set disabled CLIENT side. It therefore didn't have theaspNetDisabledCSS class. By moving the client-side logic to disable that field across to the server, the CSS class was being set and ASP.Net was restoring the value from ViewState. (Fairly obviously, just adding theaspNetDisabledclassname at the client won't do the trick, as the classname doesn't get posted back). I know, it's one of those things I should have known, and I know, too, that I should be doing things like enabling fields consistently - either client-side or server-side. My original code did it server-side, but that involved writing a line of code for each control. The later add -
Well, maybe this isn't weird, and it's relating to ASP.Net Webforms so of no relevance to most of you anyway... but even though I've been using ASP.Net webforms for donkey's years, this is something I'd not realised / understood until just now. I have a form on which some of the fields may be disabled, depending on some rather complex logic. Some of the fields are disabled dependent on one of several statuses of a business object; others are disabled depending on a boolean flag that is available client-side. Some are dependent on both tests. I was finding that when posting back, ONE of the fields was "losing" it's value, and the underlying database was getting an empty value. (Fortunately auditing at the database level was tracking the changes in values, so in those cases it happened in the live system I was able to restore via the audit trail. I knew it would be useful!) Debugging in VS it was apparent that although both fields were disabled (and had the
disabled="disabled"attribute), one was empty right at the start of thepage_loadevent, whilst the other had the value expected. I know that disabled fields aren't posted back as part of the HTTP post, but ASP.Net was "restoring" the value (I understand through ViewState). What I couldn't figure out was why ASP.Net was restoring some disabled fields, but not others. Eventually I noticed that the one that had the expected value hadaspNetDisabledin the CSS class attribute client-side (as well as my own class name). Investigating showed that ASP.Net adds this attribute when the field is set to disabled at the server. It turns out that my code, which had evolved over years, had one set of "disabling" rules implemented server-side, by settingfield.Enabled = false... but the field that was returning blank, was getting set disabled CLIENT side. It therefore didn't have theaspNetDisabledCSS class. By moving the client-side logic to disable that field across to the server, the CSS class was being set and ASP.Net was restoring the value from ViewState. (Fairly obviously, just adding theaspNetDisabledclassname at the client won't do the trick, as the classname doesn't get posted back). I know, it's one of those things I should have known, and I know, too, that I should be doing things like enabling fields consistently - either client-side or server-side. My original code did it server-side, but that involved writing a line of code for each control. The later addQuote:
A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.
This isn't one of those times.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
Well, maybe this isn't weird, and it's relating to ASP.Net Webforms so of no relevance to most of you anyway... but even though I've been using ASP.Net webforms for donkey's years, this is something I'd not realised / understood until just now. I have a form on which some of the fields may be disabled, depending on some rather complex logic. Some of the fields are disabled dependent on one of several statuses of a business object; others are disabled depending on a boolean flag that is available client-side. Some are dependent on both tests. I was finding that when posting back, ONE of the fields was "losing" it's value, and the underlying database was getting an empty value. (Fortunately auditing at the database level was tracking the changes in values, so in those cases it happened in the live system I was able to restore via the audit trail. I knew it would be useful!) Debugging in VS it was apparent that although both fields were disabled (and had the
disabled="disabled"attribute), one was empty right at the start of thepage_loadevent, whilst the other had the value expected. I know that disabled fields aren't posted back as part of the HTTP post, but ASP.Net was "restoring" the value (I understand through ViewState). What I couldn't figure out was why ASP.Net was restoring some disabled fields, but not others. Eventually I noticed that the one that had the expected value hadaspNetDisabledin the CSS class attribute client-side (as well as my own class name). Investigating showed that ASP.Net adds this attribute when the field is set to disabled at the server. It turns out that my code, which had evolved over years, had one set of "disabling" rules implemented server-side, by settingfield.Enabled = false... but the field that was returning blank, was getting set disabled CLIENT side. It therefore didn't have theaspNetDisabledCSS class. By moving the client-side logic to disable that field across to the server, the CSS class was being set and ASP.Net was restoring the value from ViewState. (Fairly obviously, just adding theaspNetDisabledclassname at the client won't do the trick, as the classname doesn't get posted back). I know, it's one of those things I should have known, and I know, too, that I should be doing things like enabling fields consistently - either client-side or server-side. My original code did it server-side, but that involved writing a line of code for each control. The later addYou should add it as a tip
In Word you can only store 2 bytes. That is why I use Writer.