How to determine if button should be shown?
-
What an idiot. Clearly he should have done.
button37.Visible = textBox39.BackColor == Color.White && textBox40.BackColor == Color.PapayaWhip;
cheers, Chris Maunder The Code Project Co-founder Microsoft C++ MVP
You know what is worst in this situation? That, this was my first thought. Idea of putting background color into the condition fits so perfect in his methodology, that I missed it first.
-
<Homer> Mmmm... papaya whip... </Homer>
Brilliant! Well, I'm a great The Simpsons fan. I truly heard Homer saying it.
-
We are dealing with application left by our former developer. I could mention here a lot of things like putting all of the code in one file (15k lines, 680kB), putting all controls on one form and using
BringToFront, naming all controls liketextBox85, hardcoding the same connection string in three different places, and so on. But criteria if one of the buttons should be shown beats all of it:if ((textBox39.BackColor == Color.White) && (textBox40.BackColor == Color.PapayaWhip))
button37.Visible=true;
else
button37.Visible=false;jkruza wrote:
naming all controls like textBox85
Yikes! I cannot stand it when people do that. My course I teach, I penalize points from students who name controls in this manner, and people still do it (then they wonder why they receive a lower grade than the grade they think they were going to earn) :laugh:
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon "Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
-
jkruza wrote:
naming all controls like textBox85
Yikes! I cannot stand it when people do that. My course I teach, I penalize points from students who name controls in this manner, and people still do it (then they wonder why they receive a lower grade than the grade they think they were going to earn) :laugh:
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon "Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
Paul Conrad wrote:
Yikes! I cannot stand it when people do that.
Not so bad with one or 2... but considering that it is "85" that is a whole lot of tb's and no way to know what is with what or what has been deleted et cetera et cetera. Gives me a headache just thinking about. Man am I glad we have standards. I would like to say people have been fired for less, but that would be a lie. That would be somewhere I would enjoy working though:thumbsup:
"9 Pregnent woman can not have a baby in 1 month" -Uknown
-
We are dealing with application left by our former developer. I could mention here a lot of things like putting all of the code in one file (15k lines, 680kB), putting all controls on one form and using
BringToFront, naming all controls liketextBox85, hardcoding the same connection string in three different places, and so on. But criteria if one of the buttons should be shown beats all of it:if ((textBox39.BackColor == Color.White) && (textBox40.BackColor == Color.PapayaWhip))
button37.Visible=true;
else
button37.Visible=false;naming all controls like textBox85 I wish Microsoft had made it easy (if not default) to have VS ask the name of new objects being created, especially since the text field will get initialized to the default name (so even if the name and text field should be the same, both will have to be keyed in). BTW, any recommendations for the best plug-in for 2005 and 2008 to fix that?
-
naming all controls like textBox85 I wish Microsoft had made it easy (if not default) to have VS ask the name of new objects being created, especially since the text field will get initialized to the default name (so even if the name and text field should be the same, both will have to be keyed in). BTW, any recommendations for the best plug-in for 2005 and 2008 to fix that?
Looking at the type of code and namings I would hazard a guess that this might have been taken from code that was decompile using reflector etc. That would be borne out by the use of three hard coded connection strings too. It may have originally been a single constant. Not that this is an excuse or mitigates the situation. Anyone who has to rip code to that extent needs to get a new career! :wtf:
-
Looking at the type of code and namings I would hazard a guess that this might have been taken from code that was decompile using reflector etc. That would be borne out by the use of three hard coded connection strings too. It may have originally been a single constant. Not that this is an excuse or mitigates the situation. Anyone who has to rip code to that extent needs to get a new career! :wtf:
Even if it was decompiled, that would still mean that all the show / hide conditions are tied to various color settings. Anyone who has to rip code to that extent needs a freaking lobotomy.
------------------------------- Carrier Bags - 21st Century Tumbleweed.
-
We are dealing with application left by our former developer. I could mention here a lot of things like putting all of the code in one file (15k lines, 680kB), putting all controls on one form and using
BringToFront, naming all controls liketextBox85, hardcoding the same connection string in three different places, and so on. But criteria if one of the buttons should be shown beats all of it:if ((textBox39.BackColor == Color.White) && (textBox40.BackColor == Color.PapayaWhip))
button37.Visible=true;
else
button37.Visible=false;This retina scarring horror jumped out the screen and tried to garrote me with a cheese wire. :omg:
------------------------------- Carrier Bags - 21st Century Tumbleweed.
-
Even if it was decompiled, that would still mean that all the show / hide conditions are tied to various color settings. Anyone who has to rip code to that extent needs a freaking lobotomy.
------------------------------- Carrier Bags - 21st Century Tumbleweed.
Even if it was decompiled, that would still mean that all the show / hide conditions are tied to various color settings. Anyone who has to rip code to that extent needs a freaking lobotomy. I've seen code like that on systems from any era that supported color (it would be rather hard to use such code on a system that didn't). Many types of controls support a 'tag' property which could be pointed to a sensible object including all necessary ancillary information, but some controls don't. If there's no need to serialize the controls, color might not be totally horrible if one used constants named based upon [i]meaning[/i] and explicitly stated in the comments that all values must be unique (I think the use of a Select Case construct somewhere could enforce that requirement). I would consider the following horrible: If ThisThing.Color = Colors.Red Then ThisThing.Delete but I would consider If ThisThing.Color = FlagColors.Deletable Then ThisThing.Delete to be rather less horrible. I would guess that both pieces of source would yield identical compiled code, however, so a disassembler would guess at the former meaning.
-
You know what is worst in this situation? That, this was my first thought. Idea of putting background color into the condition fits so perfect in his methodology, that I missed it first.
jkruza wrote:
Idea of putting background color into the condition fits so perfect in his methodology, that I missed it first.
Doesn't everyone use background colors for their control logic? ;) :laugh: This code probably even works, but see my tag line…
Just because the code works, it doesn't mean that it is good code.