Connecting signal from QDialog to slot from MainWindow classes

[d_stranz]

Anyway, the table model is not updated, but this is an issue I'll have to address later.

I use the following pattern whenever I implement a dialog that collects non-trivial information from the user which then must be passed back to the main program:

- create a struct or class that holds the data to be filled in by the dialog. Both the dialog and the main window know about this struct
- before posting the dialog, fill an instance of the struct with appropriate default values
- store the struct instance in the dialog instance
- exec() the dialog
- if exec() returns QDialog::Rejected, do nothing
- if exec() returns QDialog::Accepted then do the following
- retrieve the modified copy of the struct from the dialog
- process it as appropriate to store it in the main app

The code would roughly go like this:

void MainWindow::on_actionAdd_New_triggered()
{
    AddRecipe addRecipes ( this );
    RecipeTemplate  newRecipe;  // the struct, filled by default values on construction
    addRecipes.setRecipeTemplate( newRecipe );
    if ( QDialog::Accepted == addRecipes.exec() )
    {
      newRecipe = addRecipes.getNewRecipe();
      addNewRecipeToDB( newRecipe );
    }
}

void MainWindow::on_actionAdd_New_triggered()
{
    AddRecipe addRecipes ( this );
    RecipeTemplate  newRecipe;  // the struct, filled by default values on construction
    addRecipes.setRecipeTemplate( newRecipe );
    if ( QDialog::Accepted == addRecipes.exec() )
    {
      newRecipe = addRecipes.getNewRecipe();
      addNewRecipeToDB( newRecipe );
    }
}

To copy to clipboard, switch view to plain text mode 

The dialog doesn't need any extra signals or slots, nor do I need to connect to any existing signals. Everything is handled internally to the MainWindow slot.

[editheraven]

I'll try this when I'll come from work.
As I can see, this works almost like a callback function system.

le : well I actually had too add

emit accepted();

emit accepted();

To copy to clipboard, switch view to plain text mode 

to be able to update my table.

[d_stranz]

As I can see, this works almost like a callback function system.

Signals and slots are similar to that, yes. But in order for your dialog to do anything useful, it has to be able to communicate that to the rest of the program. So the callback (MainWindow slot in this case) has to receive data from the dialog. When calling this slot (by way of a signal), the dialog has to pass that information along.

So an alternative to my pattern above would be similar to what is used in QFileDialog: whenever the user changes to a new directory, selects a different file extension from the combobox, or selects a file, QFileDialog emits a signal that notifies of the change. For your AddRecipe dialog to work the same way, it would have to emit a signal that contains the data the user has entered for the new recipe, and MainWindow needs a slot to receive that data. A signal / slot pair that don't transmit any information (like your show_table() slot) means that you have to find some alternative means to get the information from the dialog.

I use the QFileDialog pattern when I need to keep track of changes occurring in the dialog while the dialog is still posted (like an "Apply" button that updates the main UI based on the current settings being defined in the dialog). If I don't need that, I generally use the pattern I described in the previous post.