SQL Queries and passing to Child Dialogs, best practices?
I have a main window that connects to a DB (MySQL in AWS) to show table data. I have child dialog windows that also query the DB to show/update table data, so I have created signals so that the child windows can pass any necessary variables or queries to the main window which runs the actual query.
(I did this to try and cut down on having multiple connections to the DB unnecessarily instead of having each window or dialog connect individually, and then disconnect upon close).
I now need grand-child dialogs that can do the same. Having signals/slots from the main window->child dialog->grand-child dialog seems overly cumbersome.
Is there a better way? Should I not worry about having too many connections and just have each window/dialog connect to the DB individually?
It depends on how you want your software to manage the database connection(s).
Only one can be enough.
@SGaist How would you recommend passing data between grant-parent/grand-child Windows with only one connection?
What kind of data do you want to pass ?
Usually with dialogs the process is:
- parent create the child dialog
- parent calls
- if the user clicked ok the parent reads the data directly exposed via getters
- the parent does stuff with that data
@SGaist I would like to pass a QSqlQueryModel.
@VRonin I am wondering if there is a way for my dialog, which is a child of a child of a main window to access a getter function of the main window, without having to have an intermediary getter function in the ‘middle’ dialog.
How should I point to a dialog’s parent’s parent?
If you have to go in such deep levels, then there's likely an architecture problem.
What exactly are you trying to achieve ?
@SGaist I am creating a desktop application to handle inventory movement between multiple warehouses and for multiple projects.
The MainWindow shows general information about what inventory is on hand at each location for each project.
A child Dialog, lets call it "CreateTransaction" is used for creating a new 'transaction' or shipment of inventory between warehouses. This dialog shows information about the individual shipment (tracking info, shipment dates, and what various part#'s and QTY's are in the shipment).
While a user is creating a transaction, I would like them to be able to get a list of all the available inventory part#'s and QTY's in the warehouse that they are shipping from. So to add each individual line item to a shipment a child of "CreateTransaction" is created. Lets call it "AddTransactionLine". A user may add one, or several lines of different inventory to a transaction.
AddTransactionLine is a child of CreateTransaction, which is a child of MainWindow (which handles the DB connection).
AddTransactionLine should be able to query the database to get a table. The user selects qty's from the table, and then will pass that info along to "CreateTransaction" to actually add them as a "line" in the shipment.
I would like to avoid having to build the part where you add individual line items to a "transaction" into the UI of CreateTransaction as it would look cluttered, and most other inventory programs I have used in the past use this same kind of 3-tiered logic of Home Screen > Create A Shipment > Add things to that shipment.
I think I have my solution: Pass a pointer to a class instantiated by the MainWindow to each subsequent dialog(s) and save it as a member. The object instance I am passing, call it "DatabseObject" has getter functions that run queries, return models, etc. This way any dilalog can call a getter function on my DatabaseObject, without creating a long series of siganls/slots.
1. MainWindow instantiates object of class "Database" as *m_pDBO (DBO = database object). 2. MainWindow passes m_pDBO to any dialogs created, they also save it as a *m_pDBO. 3. Any further dialogs created by dialogs, get passed m_pDBO.
Any comments, better methods, or reasons why I should not do this are always appreciated!
No, bad design. The child should never even know who its parent is.
The correct process is to push information downstream.
The child should have setters for all the data it need. The manwindow calls those setters.