Did you ever...
-
Is he working with you on the same project and you guys are taking up this fight at CP? :~
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]
-
Is he working with you on the same project and you guys are taking up this fight at CP? :~
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]
-
Star Vega wrote:
If he likes working on classes of 47 000 lines of code, this might be the case!
Reminds me of my previous project, which was an absolute nightmare. Google for "Nightly session drop".
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... ;)
I guess this approach is designed to make the initial load heavier - but then the running of the app faster (as flicking visibility on/off is lighter than instantiating). Adv: Faster app. speed Dis: More complex coding Longer dev. cycles Bug incidents more likely (due to complexity) Longer initial load speed More memory needed when using the application Expert friendly Instead of a list you might want to recode a particularly complex screen/page/whatever and then calculate some metrics: memory usage application speed load speed LoC etc. So if you are right you would be able to say: 'Rewriting this ____ has made it much less complex to maintain as there is 50% less code, which will mean less bugs. The load speed is 40% better and the memory usage is 60% down. The impact to application speed has been negligible.'
"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. .
-
What about them? Panel - CBuilder or Delphi custom control I think so no use to me as we only use Win32 API. Tabcontrol - Use them all the time but around a dialog not emebedded into it as an embedded tab control takes up at least one lines worth of space that could be used for other controls. We already switch from multi-line tab controls to single line when running on a low desktop resolution. Usercontrol - Not sure what you mean. I've written an equivilent of the listview that handles an undefined number of items whilst only loading enought items to fill the window. When dealing with a client/server app it's important to keep network traffic at a minimum. Run-time controls - Again, not sure what you mean. All of our controls are dynamically created and enabled/disabled at runtime based on our own dialog template library.
-
Star Vega wrote:
If he likes working on classes of 47 000 lines of code, this might be the case!
Reminds me of my previous project, which was an absolute nightmare. Google for "Nightly session drop".
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]
-
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++]