At The Risk Of Being Excoriated...
-
I'm back at it, trying to build an app to manage substation equipment. I had to take a little break to design a substation and some new sewer plant motor control circuits, but I'm back at it and still confused. Before you tell me to read a book, I have read two, and ordered another. But the third book won't arrive until Friday, and I have a five day weekend for the Thanksgiving holiday I'd like not to waste. I've also reduced the scope of the problem to manage one kind of device, instead of tackling 4 different types with entirely different information to manage. I figure that if I can get one to work, it won't be nearly as hard to expand as it would be to write it all at once. I have a SQL Server DB with several tables - a master that holds equipment information that is invariant, a status table that holds information about the current location, last service date, and number of operations since last service, and a pair of tables to hold the histories of readings taken and services performed on each device. I have created a boilerplate app with a main form, and that form has a menu to allow the user to Add, Edit, Move, Service, Read, or View devices. I know this is easy to anyone who does it all the time, but I am well and truly stuck for ideas about where to go from here. I've tried before to use a sequence of forms, hiding and showing them, to walk a user through a few pages of data entry, but it turned out to be problematic to transfer the data between forms. I've tried using dialog boxes for each step, but had similar problems. I tried using data-bound controls on each form but that quickly became a nightmare, so I'm leaning toward a solution that has the main form collect all the data, then pass it off to functions that update the database. Besides, I believe the separation of data functions and user interface makes good sense from a maintenance point of view. Is this a place where a MDI is appropriate? Or is the idea of using multiple forms in sequence a better approach? Or should I stick with one form and change the visibility of controls as the user moves through the process. I'm lost here. I think the question is one of architecture, rather than procedure or actual coding, but I don't know if I'm even asking the right questions yet. I've read lots of stuff about making and using forms, but not one example of using two or more in the same app has appeared anywhere I've searched. That leads me to believe that I'm barking up the wrong tree entirely, and there's some secret method used by a
-
I'm back at it, trying to build an app to manage substation equipment. I had to take a little break to design a substation and some new sewer plant motor control circuits, but I'm back at it and still confused. Before you tell me to read a book, I have read two, and ordered another. But the third book won't arrive until Friday, and I have a five day weekend for the Thanksgiving holiday I'd like not to waste. I've also reduced the scope of the problem to manage one kind of device, instead of tackling 4 different types with entirely different information to manage. I figure that if I can get one to work, it won't be nearly as hard to expand as it would be to write it all at once. I have a SQL Server DB with several tables - a master that holds equipment information that is invariant, a status table that holds information about the current location, last service date, and number of operations since last service, and a pair of tables to hold the histories of readings taken and services performed on each device. I have created a boilerplate app with a main form, and that form has a menu to allow the user to Add, Edit, Move, Service, Read, or View devices. I know this is easy to anyone who does it all the time, but I am well and truly stuck for ideas about where to go from here. I've tried before to use a sequence of forms, hiding and showing them, to walk a user through a few pages of data entry, but it turned out to be problematic to transfer the data between forms. I've tried using dialog boxes for each step, but had similar problems. I tried using data-bound controls on each form but that quickly became a nightmare, so I'm leaning toward a solution that has the main form collect all the data, then pass it off to functions that update the database. Besides, I believe the separation of data functions and user interface makes good sense from a maintenance point of view. Is this a place where a MDI is appropriate? Or is the idea of using multiple forms in sequence a better approach? Or should I stick with one form and change the visibility of controls as the user moves through the process. I'm lost here. I think the question is one of architecture, rather than procedure or actual coding, but I don't know if I'm even asking the right questions yet. I've read lots of stuff about making and using forms, but not one example of using two or more in the same app has appeared anywhere I've searched. That leads me to believe that I'm barking up the wrong tree entirely, and there's some secret method used by a
Wrong forum so consider yourself .... Excoriated, where the bloody dictionary when I need it. The is definitely a design issue and we all have our favourite flavours. Here is mine, caveat most of my apps a batch management so no transactions to speak of. Main form with a navigation control on the left, menu for methods not based on a specific piece of data (exit, process, help and reports), an icon strip for CRUD keys Changing selection in the nav control populates a list in the main body of the form. From the list you pop a dialog ALWAYS, never edit in a list control. You can either pass an ID or an object to the dialog in the constructor. Your list has the ID of the records you want to work with so I pass that to a dialog designed to work with that object. When the dialog is opened it inspects the ID passed in, if you passed a 0 (ADD) then it gets an empty datatable from the database, if there is an id (EDIT) then it gets that record from the database. The class that gets the datatable (designed for that object) also populates the object. I then bind the form to the object. When the user edits the form the data is passed to the object via the binding. When the user saves the dialog I write the data back to the database and return DialogResult.OK to the main form and closes. Main form detects the OK and reloads the list control with the new record. I rarely need more than 3 levels of nested dialogs for any operation. BTW, Last Serviced date is redundant on the Tool table, Select top 1 from service table should do it. Otherwise you need to reconcile between the last service field and the service table, what happens if someone deletes a service record?
-
Wrong forum so consider yourself .... Excoriated, where the bloody dictionary when I need it. The is definitely a design issue and we all have our favourite flavours. Here is mine, caveat most of my apps a batch management so no transactions to speak of. Main form with a navigation control on the left, menu for methods not based on a specific piece of data (exit, process, help and reports), an icon strip for CRUD keys Changing selection in the nav control populates a list in the main body of the form. From the list you pop a dialog ALWAYS, never edit in a list control. You can either pass an ID or an object to the dialog in the constructor. Your list has the ID of the records you want to work with so I pass that to a dialog designed to work with that object. When the dialog is opened it inspects the ID passed in, if you passed a 0 (ADD) then it gets an empty datatable from the database, if there is an id (EDIT) then it gets that record from the database. The class that gets the datatable (designed for that object) also populates the object. I then bind the form to the object. When the user edits the form the data is passed to the object via the binding. When the user saves the dialog I write the data back to the database and return DialogResult.OK to the main form and closes. Main form detects the OK and reloads the list control with the new record. I rarely need more than 3 levels of nested dialogs for any operation. BTW, Last Serviced date is redundant on the Tool table, Select top 1 from service table should do it. Otherwise you need to reconcile between the last service field and the service table, what happens if someone deletes a service record?
Thanks for some excellent advice! It actually makes sense to me. :-D One of the approaches I first considered was to make a master page that spawns dialog boxes to collect information, then passes the result back to the main form. I forget why I abandoned it. As for the forum choice, my other choice was general programming, and it had more cobwebs than visitors last time I looked. About the last service date... I had planned to update a device status table with that info every time a service is performed in order to provide a concise, small table that I can use to give users a quick, easy report to show which devices are nearing a service appointment. If a service record gets deleted, no big deal - the critical data is recorded elsewhere. Similarly, whenever a new reading for the operation counter of a device is entered, it's cumulative operations since the last service will also be stored in the status table. These devices are good for about 50 operations before they fail if service is not performed, so this information has to be really easy to find. At $18,000 each, we don't keep many spares on hand, and can't afford to lose one! :-D BTW - My new book arrived today - Programming Microsoft SQL Server 2008 - and it looks fairly complete. All the code is written in C#, too, rather than the VB I don't have any interest in learning at the moment. It's looking to be a fun weekend! Thanks, again!
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Thanks for some excellent advice! It actually makes sense to me. :-D One of the approaches I first considered was to make a master page that spawns dialog boxes to collect information, then passes the result back to the main form. I forget why I abandoned it. As for the forum choice, my other choice was general programming, and it had more cobwebs than visitors last time I looked. About the last service date... I had planned to update a device status table with that info every time a service is performed in order to provide a concise, small table that I can use to give users a quick, easy report to show which devices are nearing a service appointment. If a service record gets deleted, no big deal - the critical data is recorded elsewhere. Similarly, whenever a new reading for the operation counter of a device is entered, it's cumulative operations since the last service will also be stored in the status table. These devices are good for about 50 operations before they fail if service is not performed, so this information has to be really easy to find. At $18,000 each, we don't keep many spares on hand, and can't afford to lose one! :-D BTW - My new book arrived today - Programming Microsoft SQL Server 2008 - and it looks fairly complete. All the code is written in C#, too, rather than the VB I don't have any interest in learning at the moment. It's looking to be a fun weekend! Thanks, again!
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Roger Wright wrote:
it had more cobwebs than visitors
True, the reason you got a sensible reply (although posting here is the reason there is bare):sigh: The reason NOT to use the service date on the tool record is that it sets a bad habit and will lead to disaster, sooner or later the auditing of the related data is going to be critical and if you have it in 2 places (tool and service) then reconciliation is an issue. This is a BASIC tenant of database design, called normalisation, no data should be stored in more than one place. There are exceptions but they are EXCEPTIONs.
-
I'm back at it, trying to build an app to manage substation equipment. I had to take a little break to design a substation and some new sewer plant motor control circuits, but I'm back at it and still confused. Before you tell me to read a book, I have read two, and ordered another. But the third book won't arrive until Friday, and I have a five day weekend for the Thanksgiving holiday I'd like not to waste. I've also reduced the scope of the problem to manage one kind of device, instead of tackling 4 different types with entirely different information to manage. I figure that if I can get one to work, it won't be nearly as hard to expand as it would be to write it all at once. I have a SQL Server DB with several tables - a master that holds equipment information that is invariant, a status table that holds information about the current location, last service date, and number of operations since last service, and a pair of tables to hold the histories of readings taken and services performed on each device. I have created a boilerplate app with a main form, and that form has a menu to allow the user to Add, Edit, Move, Service, Read, or View devices. I know this is easy to anyone who does it all the time, but I am well and truly stuck for ideas about where to go from here. I've tried before to use a sequence of forms, hiding and showing them, to walk a user through a few pages of data entry, but it turned out to be problematic to transfer the data between forms. I've tried using dialog boxes for each step, but had similar problems. I tried using data-bound controls on each form but that quickly became a nightmare, so I'm leaning toward a solution that has the main form collect all the data, then pass it off to functions that update the database. Besides, I believe the separation of data functions and user interface makes good sense from a maintenance point of view. Is this a place where a MDI is appropriate? Or is the idea of using multiple forms in sequence a better approach? Or should I stick with one form and change the visibility of controls as the user moves through the process. I'm lost here. I think the question is one of architecture, rather than procedure or actual coding, but I don't know if I'm even asking the right questions yet. I've read lots of stuff about making and using forms, but not one example of using two or more in the same app has appeared anywhere I've searched. That leads me to believe that I'm barking up the wrong tree entirely, and there's some secret method used by a