Did you ever...
-
Did you ever felt the need to put controls on top of each other? So you can set them visible/invisible depending on the situation? This project I have to 'debug' is full of it... You have a button over a textbox over a panel over a groupbox and so on ! The guys here wonder why I do not like this practice. Can you tell me why you wouldn't do this, so I can offer them a LIST of reasons... ;)
Rarely. The most recent example is a form that can be used for both adding and updating a record, so I put the "Add" and "Update" buttons on top of each other. Changing the text wouldn't have worked, because I'd also have needed to rewire the events. Reading the other comments, I've come to realize that a custom 2 state button would have been better, with separate add/update events and a state flag that, when changed, would change the text and also fire the correct event when the button was clicked. Hmmm.... Marc
-
Rarely. The most recent example is a form that can be used for both adding and updating a record, so I put the "Add" and "Update" buttons on top of each other. Changing the text wouldn't have worked, because I'd also have needed to rewire the events. Reading the other comments, I've come to realize that a custom 2 state button would have been better, with separate add/update events and a state flag that, when changed, would change the text and also fire the correct event when the button was clicked. Hmmm.... Marc
Marc Clifton wrote:
Hmmm....
Go on Marc! I know you want to! It's just a few lines of code...
-- Kein Mitleid Für Die Mehrheit
-
Yep, a good comparison indeed - I'm in the middle of it! Did this 'Monster' experience bring something good for you? Or is it just an enormous waste of time? (I go for the second option)
Some time was wasted in that, but I wouldn't say it was a total waste. I learned a few goodies by working on that project. But nevertheless, a total nightmare.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]
-
Rarely. The most recent example is a form that can be used for both adding and updating a record, so I put the "Add" and "Update" buttons on top of each other. Changing the text wouldn't have worked, because I'd also have needed to rewire the events. Reading the other comments, I've come to realize that a custom 2 state button would have been better, with separate add/update events and a state flag that, when changed, would change the text and also fire the correct event when the button was clicked. Hmmm.... Marc
Marc Clifton wrote:
I've come to realize that a custom 2 state button would have been better, with separate add/update events and a state flag that, when changed, would change the text and also fire the correct event when the button was clicked.
Nice. I like that idea.
Simon
-
Did you ever felt the need to put controls on top of each other? So you can set them visible/invisible depending on the situation? This project I have to 'debug' is full of it... You have a button over a textbox over a panel over a groupbox and so on ! The guys here wonder why I do not like this practice. Can you tell me why you wouldn't do this, so I can offer them a LIST of reasons... ;)
That becomes a maintenance nightmare. Property sheets and tabs are better if there are many controls. Changing control text is another option. If that fails a custom/user control is another option. In short avoid it like plague. I personally will hate to debug such code, because in my first job it was like that and I never liked the job.
Proud to be a CPHog user
-
Did you ever felt the need to put controls on top of each other? So you can set them visible/invisible depending on the situation? This project I have to 'debug' is full of it... You have a button over a textbox over a panel over a groupbox and so on ! The guys here wonder why I do not like this practice. Can you tell me why you wouldn't do this, so I can offer them a LIST of reasons... ;)
The closest I come to that is having a static control on a dialog as a placeholder for another control (like an ActiveX instantiation) I'm creating dynamically. I get the location of the static, destroy it, and then create the desired 'dynamic' control. I have had dialogs with groups of controls, where only one group of controls was visible at a time. The dialog layout in the resources had nothing to do with the final appearance, as the dialog automatically laid out its child controls. This was a special case, however, where a child dialog or a property page wasn't an appropriate solution.
Software Zen:
delete this; -
Did you ever felt the need to put controls on top of each other? So you can set them visible/invisible depending on the situation? This project I have to 'debug' is full of it... You have a button over a textbox over a panel over a groupbox and so on ! The guys here wonder why I do not like this practice. Can you tell me why you wouldn't do this, so I can offer them a LIST of reasons... ;)
* Because it is harder to maintain. ==> when you want to select one item you must remove the items above it. * Because it is much better to handle the texts and behaviors programmatically. * Because it is faster to program than to assign properties. It is slow to assign properties to all the controls and if you must do it for several controls it is painfully slow... * Because you are consuming more memory. * Because you must have several handlers for the several items involved. ... Hope this helps... PS: In the PLC world, several times we are using poor displays that have limited options and some times we must make this kind of things, but it is painful to reuse everything, my rule of thumb is: if you have enough horsepower use it, don't rely on bad practices... :rolleyes:
-
Did you ever felt the need to put controls on top of each other? So you can set them visible/invisible depending on the situation? This project I have to 'debug' is full of it... You have a button over a textbox over a panel over a groupbox and so on ! The guys here wonder why I do not like this practice. Can you tell me why you wouldn't do this, so I can offer them a LIST of reasons... ;)
I've done it for simple cases. (Like Marc's update/add button). But for more than 2 controls, I would use something else. Primary reason for not doing it would be complexity. windows forms is ugly enough anyway, when you start stacking controls on top of each other you can't see what's there, and reading the code to work it out isn't really an option.
Simon
-
That becomes a maintenance nightmare. Property sheets and tabs are better if there are many controls. Changing control text is another option. If that fails a custom/user control is another option. In short avoid it like plague. I personally will hate to debug such code, because in my first job it was like that and I never liked the job.
Proud to be a CPHog user
Rama Krishna Vavilala wrote:
That becomes a maintenance nightmare.
Maybe, but it sounds like you are building the software for you, not for the user. You need to do what is best for the user experience, not what is easiest for the developer. In some cases, dynamically showing/hiding controls in response to user input is the correct thing to do, and the fact that it makes your life as a developer harder is not important.
-
* Because it is harder to maintain. ==> when you want to select one item you must remove the items above it. * Because it is much better to handle the texts and behaviors programmatically. * Because it is faster to program than to assign properties. It is slow to assign properties to all the controls and if you must do it for several controls it is painfully slow... * Because you are consuming more memory. * Because you must have several handlers for the several items involved. ... Hope this helps... PS: In the PLC world, several times we are using poor displays that have limited options and some times we must make this kind of things, but it is painful to reuse everything, my rule of thumb is: if you have enough horsepower use it, don't rely on bad practices... :rolleyes:
Very well put pal. :)
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]
-
I've done it for simple cases. (Like Marc's update/add button). But for more than 2 controls, I would use something else. Primary reason for not doing it would be complexity. windows forms is ugly enough anyway, when you start stacking controls on top of each other you can't see what's there, and reading the code to work it out isn't really an option.
Simon
I work in software localization and part of that is that we have to resize dialog controls to fit the translated text. Dialogs with stacked controls are a frickin' nightmare! Edit: Odd. I was sure I replied to the OP...
modified on Tuesday, September 23, 2008 7:36 AM
-
Very well put pal. :)
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]
Isn't Joan a she?
-
Isn't Joan a she?
There we go. Much better now. :-D
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]
-
Rama Krishna Vavilala wrote:
That becomes a maintenance nightmare.
Maybe, but it sounds like you are building the software for you, not for the user. You need to do what is best for the user experience, not what is easiest for the developer. In some cases, dynamically showing/hiding controls in response to user input is the correct thing to do, and the fact that it makes your life as a developer harder is not important.
For one or two releases that might work fine. Everyone might be happy. But now a user wants a new feature, he wants more controls. A developer adds more and more controls. The screen becomes such a mess that user cannot get the new feature out from it or in time and budget. If a software product is used once and only once such a practice will be OK, but if a software product has to survive for a long time with customer requests translating into new features in a reasonable time than it is always better to write maintainable code.
Graham Bradshaw wrote:
You need to do what is best for the user experience, not what is easiest for the developer.
These are not orthogonal concepts and no excuse for writing non maintainable code. It is generally always possible to write maintainable code which produces best user experience. In the case of OP there are several such options are available.
Proud to be a CPHog user
-
For one or two releases that might work fine. Everyone might be happy. But now a user wants a new feature, he wants more controls. A developer adds more and more controls. The screen becomes such a mess that user cannot get the new feature out from it or in time and budget. If a software product is used once and only once such a practice will be OK, but if a software product has to survive for a long time with customer requests translating into new features in a reasonable time than it is always better to write maintainable code.
Graham Bradshaw wrote:
You need to do what is best for the user experience, not what is easiest for the developer.
These are not orthogonal concepts and no excuse for writing non maintainable code. It is generally always possible to write maintainable code which produces best user experience. In the case of OP there are several such options are available.
Proud to be a CPHog user
Rama Krishna Vavilala wrote:
better to write maintainable code.
Better than what, exactly?
-
Did you ever felt the need to put controls on top of each other? So you can set them visible/invisible depending on the situation? This project I have to 'debug' is full of it... You have a button over a textbox over a panel over a groupbox and so on ! The guys here wonder why I do not like this practice. Can you tell me why you wouldn't do this, so I can offer them a LIST of reasons... ;)
It is symptomatic of drag and drop based design.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego. -
Placing control over control over co... I wouldn't do it, because that is the mark of an asshole.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]
-
Did you ever felt the need to put controls on top of each other? So you can set them visible/invisible depending on the situation? This project I have to 'debug' is full of it... You have a button over a textbox over a panel over a groupbox and so on ! The guys here wonder why I do not like this practice. Can you tell me why you wouldn't do this, so I can offer them a LIST of reasons... ;)
On one program, but it's a dice game (Cosmic Wimpout), where not all actions are allowed all the time and only showing the currently relevant actions seems like a better design than disabling some and making the player figure out which are available. There are nine buttons in a panel and no more than three are visible at any one time, usually only one or two. On the other hand, they don't completely cover each other in the designer (that would be stupid), they only overlap; when made visible, the code has to decide where to place them as well.
-
On one program, but it's a dice game (Cosmic Wimpout), where not all actions are allowed all the time and only showing the currently relevant actions seems like a better design than disabling some and making the player figure out which are available. There are nine buttons in a panel and no more than three are visible at any one time, usually only one or two. On the other hand, they don't completely cover each other in the designer (that would be stupid), they only overlap; when made visible, the code has to decide where to place them as well.
If you're doing runtime layout anyway, why have any overlap in the designer at all?
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
Did you ever felt the need to put controls on top of each other? So you can set them visible/invisible depending on the situation? This project I have to 'debug' is full of it... You have a button over a textbox over a panel over a groupbox and so on ! The guys here wonder why I do not like this practice. Can you tell me why you wouldn't do this, so I can offer them a LIST of reasons... ;)