Forms vs Dialogs - A Question of Architecture
-
After a break to clear my head and read some more, I'm back to trying to develop a simple database program for my own use at work. Rather than continue with my previous project, I'm starting fresh. The problem - track the purchase, installation, maintenance, and movement of three types of equipment for a power company. Simple, right? I thought so, but maybe not simple enough for me yet. One approach I tried was to have the user select one of the main functions - Add, Edit, Move, Service - from the main form, then use hide/show to move to a subform for that function. My thought at the time was to then use a string of dialog boxes to walk the user through the selection of the target equipment, enter the data required (it changes depending on the equipment type), then return the data to the subform for updating the database. In my thinking, that would make it easy to simply "Add another?" from the base subform. That got rather complicated, and I got lost. The next shot was to create forms for each function and equipment type, then walk through them depending on user selections, and updating the database through the final form in each sequence. Not only is that wasteful (having all those forms lurking about whether needed or not) but it just strikes me as awful design. There ought to be a single point of control for the data access, a separate layer that is common to all functions. I just have no idea how to implement it. At the moment I have a nice Main form with a side-panel menu, a .mdb database file with sample data already loaded, and a very attractive company logo in the top left corner. I also have a nagging feeling that I'm missing something important in a conceptual way, something that hours of studying MSDN and C# programming books isn't helping. The simplistic examples used in most books aren't very useful for learning how to do real world tasks - sample programs have one Form, dialogs do only one thing, then close, etc... I've found that what I can learn from three or four helpful posts here usually exceeds what I can glean from a month or more of study, so I thought I'd give it a shot. Last time I did I received several very helpful tips that helped me a lot, and I appreciate them all. I also got a few snide, insulting comments from a few who are very active, but whose histories show that they've never once posted anything else. I've been here a long time, and I'm immune to those. Thanks, in advance, for any helpful suggestions as to how I should structure this solution to
-
After a break to clear my head and read some more, I'm back to trying to develop a simple database program for my own use at work. Rather than continue with my previous project, I'm starting fresh. The problem - track the purchase, installation, maintenance, and movement of three types of equipment for a power company. Simple, right? I thought so, but maybe not simple enough for me yet. One approach I tried was to have the user select one of the main functions - Add, Edit, Move, Service - from the main form, then use hide/show to move to a subform for that function. My thought at the time was to then use a string of dialog boxes to walk the user through the selection of the target equipment, enter the data required (it changes depending on the equipment type), then return the data to the subform for updating the database. In my thinking, that would make it easy to simply "Add another?" from the base subform. That got rather complicated, and I got lost. The next shot was to create forms for each function and equipment type, then walk through them depending on user selections, and updating the database through the final form in each sequence. Not only is that wasteful (having all those forms lurking about whether needed or not) but it just strikes me as awful design. There ought to be a single point of control for the data access, a separate layer that is common to all functions. I just have no idea how to implement it. At the moment I have a nice Main form with a side-panel menu, a .mdb database file with sample data already loaded, and a very attractive company logo in the top left corner. I also have a nagging feeling that I'm missing something important in a conceptual way, something that hours of studying MSDN and C# programming books isn't helping. The simplistic examples used in most books aren't very useful for learning how to do real world tasks - sample programs have one Form, dialogs do only one thing, then close, etc... I've found that what I can learn from three or four helpful posts here usually exceeds what I can glean from a month or more of study, so I thought I'd give it a shot. Last time I did I received several very helpful tips that helped me a lot, and I appreciate them all. I also got a few snide, insulting comments from a few who are very active, but whose histories show that they've never once posted anything else. I've been here a long time, and I'm immune to those. Thanks, in advance, for any helpful suggestions as to how I should structure this solution to
Reading you was like remembering some past adventures in programming. I remember on several occasions thinking that it was just a simple solution and it turned out not to be. For myself I just stopped thinking that, pretty much ever. That said for a nominally complex software project starting at the beginning means requirements or functional specifications, at a minimum in the form of Use Cases. Again for a small project, you then run those through some scenarios. This results in people (in this case it sounds like you are on your own, not sure) gaining a clearer picture of the realities and a level of confidence that the requirements are complete enough to begin working on things like UI design prototypes, application architecture and finally the OO Design. You might find this series of articles[^] helpful.
-
Reading you was like remembering some past adventures in programming. I remember on several occasions thinking that it was just a simple solution and it turned out not to be. For myself I just stopped thinking that, pretty much ever. That said for a nominally complex software project starting at the beginning means requirements or functional specifications, at a minimum in the form of Use Cases. Again for a small project, you then run those through some scenarios. This results in people (in this case it sounds like you are on your own, not sure) gaining a clearer picture of the realities and a level of confidence that the requirements are complete enough to begin working on things like UI design prototypes, application architecture and finally the OO Design. You might find this series of articles[^] helpful.
As always, an excellent piece of writing from Joel... Thanks for the link! It doesn't actually address my quandry, but it's a great reminder that some things never change. I was weaned on DOD-STD-2167 and MIL-STD-490, using type B5 specs. They were a pain to implement, especially for a young programmer chomping at the bit to start coding. Unit Design Folders and Interface Control Documents were a way of life, and though they weren't the fastest way to market, they remain the fastest way to market with a product that actually works. That's probably the root of my frustration with Microsoft - the shortcuts they take to be first on the shelf are the direct cause of their complete failure to release products that work correctly out of the box. The other point Joel touches on, however indirectly, is the need for technically adept tech writers, and clear documentation. Not just for the spec, but to provide pre-emptive customer support in the form of usable help and printed manuals. That was another invaluable concept killed by Microsoft. In my old age I tend to take shortcuts - no formal specs, just a written description of what the program must do. Along with that I hand craft every screen on paper, naming each control and assigning an appropriate data type to each if it has a member that must be manipulated. I also love flowcharts - I use them in my day to day work, even though it has nothing to do with software. Every task - running errands on a weekend, for instance - can be improved by writing down the flow and optimising it to make efficient use of every step. My flowcharts start out at the top level - no detailed steps, just a written visualization of what a user would do with the program, with big blocks that contain "Do something useful and save the changes somewhere." Later I expand the blocks into their own flowcharts, constantly reducing until I can almost code each block in a line or two. That works great if I have a clear idea of how the overall program structure should look, of what techniques are easy to implement and which are okay but tedious. There always exists more than one way to accomplish the job, but some ways are smarter than others. The architecture is critical, and that's what I was asking about. Yeah, I'm on my own here, which is why I'm asking. I've lived here 16 years and never met another person who can make a computer say "Hello world" without typing it in Word. :sigh:
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
After a break to clear my head and read some more, I'm back to trying to develop a simple database program for my own use at work. Rather than continue with my previous project, I'm starting fresh. The problem - track the purchase, installation, maintenance, and movement of three types of equipment for a power company. Simple, right? I thought so, but maybe not simple enough for me yet. One approach I tried was to have the user select one of the main functions - Add, Edit, Move, Service - from the main form, then use hide/show to move to a subform for that function. My thought at the time was to then use a string of dialog boxes to walk the user through the selection of the target equipment, enter the data required (it changes depending on the equipment type), then return the data to the subform for updating the database. In my thinking, that would make it easy to simply "Add another?" from the base subform. That got rather complicated, and I got lost. The next shot was to create forms for each function and equipment type, then walk through them depending on user selections, and updating the database through the final form in each sequence. Not only is that wasteful (having all those forms lurking about whether needed or not) but it just strikes me as awful design. There ought to be a single point of control for the data access, a separate layer that is common to all functions. I just have no idea how to implement it. At the moment I have a nice Main form with a side-panel menu, a .mdb database file with sample data already loaded, and a very attractive company logo in the top left corner. I also have a nagging feeling that I'm missing something important in a conceptual way, something that hours of studying MSDN and C# programming books isn't helping. The simplistic examples used in most books aren't very useful for learning how to do real world tasks - sample programs have one Form, dialogs do only one thing, then close, etc... I've found that what I can learn from three or four helpful posts here usually exceeds what I can glean from a month or more of study, so I thought I'd give it a shot. Last time I did I received several very helpful tips that helped me a lot, and I appreciate them all. I also got a few snide, insulting comments from a few who are very active, but whose histories show that they've never once posted anything else. I've been here a long time, and I'm immune to those. Thanks, in advance, for any helpful suggestions as to how I should structure this solution to
It seems not so complicated a project for you to design for. Now that you have three types of equipment, why not design three different forms for each type?It's no need to construct a perfect design in one project,at least not for this one ,right?To achieve your goal is OK,right?
Regards, Dealon Impossible is nothing!
-
As always, an excellent piece of writing from Joel... Thanks for the link! It doesn't actually address my quandry, but it's a great reminder that some things never change. I was weaned on DOD-STD-2167 and MIL-STD-490, using type B5 specs. They were a pain to implement, especially for a young programmer chomping at the bit to start coding. Unit Design Folders and Interface Control Documents were a way of life, and though they weren't the fastest way to market, they remain the fastest way to market with a product that actually works. That's probably the root of my frustration with Microsoft - the shortcuts they take to be first on the shelf are the direct cause of their complete failure to release products that work correctly out of the box. The other point Joel touches on, however indirectly, is the need for technically adept tech writers, and clear documentation. Not just for the spec, but to provide pre-emptive customer support in the form of usable help and printed manuals. That was another invaluable concept killed by Microsoft. In my old age I tend to take shortcuts - no formal specs, just a written description of what the program must do. Along with that I hand craft every screen on paper, naming each control and assigning an appropriate data type to each if it has a member that must be manipulated. I also love flowcharts - I use them in my day to day work, even though it has nothing to do with software. Every task - running errands on a weekend, for instance - can be improved by writing down the flow and optimising it to make efficient use of every step. My flowcharts start out at the top level - no detailed steps, just a written visualization of what a user would do with the program, with big blocks that contain "Do something useful and save the changes somewhere." Later I expand the blocks into their own flowcharts, constantly reducing until I can almost code each block in a line or two. That works great if I have a clear idea of how the overall program structure should look, of what techniques are easy to implement and which are okay but tedious. There always exists more than one way to accomplish the job, but some ways are smarter than others. The architecture is critical, and that's what I was asking about. Yeah, I'm on my own here, which is why I'm asking. I've lived here 16 years and never met another person who can make a computer say "Hello world" without typing it in Word. :sigh:
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Roger Wright wrote:
The architecture is critical, and that's what I was asking about.
Couple things
Roger Wright wrote:
user select one of the main functions - Add, Edit, Move, Service - from the main form
User selects from Menus and toolbars, not forms.
Roger Wright wrote:
The next shot was to create forms for each function and equipment type, then walk through them depending on user selections, and updating the database through the final form in each sequence. Not only is that wasteful (having all those forms lurking about whether needed or not) but it just strikes me as awful design. There ought to be a single point of control for the data access, a separate layer that is common to all functions.
The problem with that section is that you are coupling the UI design to the Code design. This is not correct. Arrive at a UI design from considering usability. The problems with code design are not related to UI design. Now let's talk about the last part of that section.
Roger Wright wrote:
There ought to be a single point of control for the data access, a separate layer that is common to all functions.
Yes, that and many other Software Design Patterns are already common knowledge. This statement can only have us conclude that you are not yet studied enough in design and patterns to understand the solutions to these problems. Furthermore trying to cover all that ground in an internet forum reply is not an appropriate reaction. My advice is that you stop development and continue with your studies of design and patterns. As you learn well known design principles and patterns you will recognize some of them as solutions to your current problems. Well at least that's how it works for me. ;) In case you have not seen these folks ( there are many others as well) here is where they share their expertise: Martin Fowler[^] Ward Cunningham[^]