Did you ever...
-
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... ;)
-
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... ;)
You mean, like, make a window appear above your desktop window, and give it minimise and close buttons?
-
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
I can't fit all nine buttons in the panel at once. Sure I could create them on the fly, but there's no need to in this case, each button is different and doesn't change. (Well, one button does change, but I only set its text.) Plus I wrote it four years ago, maybe I'd do it differently today.