Did you ever...
-
Donate a copy of Fowler's 'Refactoring' to the team and your 47KLoC classes will melt away!
"If you reward everyone, there will not be enough to go around, so you offer a reward to one in order to encourage everyone." Mei Yaochen in the 'Doing Battle' section of Sun Tzu's: Art of War. .
-
Donate a copy of Fowler's 'Refactoring' to the team and your 47KLoC classes will melt away!
"If you reward everyone, there will not be enough to go around, so you offer a reward to one in order to encourage everyone." Mei Yaochen in the 'Doing Battle' section of Sun Tzu's: Art of War. .
-
Donate a copy of Fowler's 'Refactoring' to the team and your 47KLoC classes will melt away!
"If you reward everyone, there will not be enough to go around, so you offer a reward to one in order to encourage everyone." Mei Yaochen in the 'Doing Battle' section of Sun Tzu's: Art of War. .
BTW, the 'team' is a group of three: me (for the time being), someone who 'learned C# in two weeks', and someone who knows a bit of VB. WTF am I doing here? (in case you would wonder) You don't want to know how 'big' this app is, and how many sales depends on it. It is a very big company I'm working for, isn't that a laugh! :omg:
-
BTW, the 'team' is a group of three: me (for the time being), someone who 'learned C# in two weeks', and someone who knows a bit of VB. WTF am I doing here? (in case you would wonder) You don't want to know how 'big' this app is, and how many sales depends on it. It is a very big company I'm working for, isn't that a laugh! :omg:
Good luck man, as the economy struggles there could be a lot of people who get stuck for a while. If you are thinking of bailing make sure that you have rock solid reasons!
"If you reward everyone, there will not be enough to go around, so you offer a reward to one in order to encourage everyone." Mei Yaochen in the 'Doing Battle' section of Sun Tzu's: Art of War. .
-
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.