QDialog closing its parent on exit..

[tescrin]

In order to abstract a problem to a global level (I know..) I've built a static "create_keypad" function that provides most of the default initialization and such.

In the current implementation I pass in a parent widget, though I've done it both ways. Either way I do it (manual memory management or garbage collection) the keypad kills my main window on exit. Because it didn't before I abstracted I have to assume it has something to do with a modal dialog box becoming some sort of "primary window" in the main event loop despite giving it my window as a parent (or not.)

Possibly the accept() or reject() signals going to the main-event loop (I'd assume..?) implies that the loop should end?

If someone could shed light on this it'd be quite helpful; as I'd prefer a generic static/global function for this task. (After all, someone else may wish to use it in the future outside of this class.) I may note that the initialization could (mostly) be abstracted to another subclass of my subclass (of QDialog), but that seems unnecessary (and I'm unsure if it's better design at that point or not.)


Snippet for completion:

class Thang : public QDialog {/*...*/};
 
static Thang* create_thang(QWidget* parent) //!!remember, with or without this parent my program quits
{
  Thang* thang = new Thang(parent);
 
  //..
  //bunch of init code..
 
  return thang;
}
 
static void use_Thang (Thang* thang)
{
  thang->exec();
 
  //..
  //special value handling/signal emission..
}

class Thang : public QDialog {/*...*/};

static Thang* create_thang(QWidget* parent) //!!remember, with or without this parent my program quits
{
  Thang* thang = new Thang(parent);

  //..
  //bunch of init code..

  return thang;
}

static void use_Thang (Thang* thang)
{
  thang->exec();

  //..
  //special value handling/signal emission..
}

To copy to clipboard, switch view to plain text mode 

Whether or not I'm critiqued on the obvious strangeness of the design, (it just feels* right to me,) I'd like to know why the loop is getting killed (or I if not, why my other windows are getting killed and thus the loop being killed.)

*[for the sake of keeping changes for the many keypads entry/exit point the same and thus the code to modify these the same/in-one-place]


Thanks for any info!

[amleto]

show a simple compilable example... read my sig (again )

[tescrin]

Hm.. I attempted to replicate the problem in a few ways on a smaller project.. but it worked as normal :s. I can't really put up the entirety of the program ( a mix of environment, external dependencies, and the thing is quite large; even if just the GUI code.)

I'll keep tinkering and report my findings.. if I figure it out before defaulting to just using member functions. I was hoping there was some (possibly obvious) oversight in my misunderstanding the event loop and static/global objects (or something along those lines.)

[Talei]

Maybe Your other (main) widget is hidden?
If Yes then closing last visible window will close app.

Try: thang->setAttribute(Qt::WA_QuitOnClose, false);

[amleto]

Hm.. I attempted to replicate the problem in a few ways on a smaller project.. but it worked as normal :s. I can't really put up the entirety of the program ( a mix of environment, external dependencies, and the thing is quite large; even if just the GUI code.)

I'll keep tinkering and report my findings.. if I figure it out before defaulting to just using member functions. I was hoping there was some (possibly obvious) oversight in my misunderstanding the event loop and static/global objects (or something along those lines.)

This is exactly the reason for making a small compilable example. Instead of asking the forum to chase ghosts, you check the problem is actually what you try to describe with 'snippets' that obviously don't contain the problem.

[wysota]

Does the program quit or does it crash?

[tescrin]

@amleto
That's what I tried to do lol, but it worked as normal. I did several tests to try and manipulate the example to be as close as possible (menu button, using an action to trigger, global/static functions, etc..) I just couldn't get it to fail. If I get 3 or 4 classes deep trying to replicate a problem; I've done what I can in a reasonable amount of time without just taking the shortcut of doing what I know works (but is more poor from a repeated code point of view.) But it's no matter because:..

@Talei
That fixed it! I didn't ever call hide on my main window.. but maybe something about this being a modal dialog (thusly pushing the other back) counts as hidden.. or something. Either way, thank you very much for the suggestion! You're obviously psychic lol. I'm guessing I've done something slightly odd with the Mainwindow's hierarchy or something (I have a separate class that controls the window in order to manage an overlay.)

@Wysota
Well I guess it's more obvious now, but it was just closing; which was part of my issue. A crash I have all sorts of tools to deal with . I had assumed crashing at first as I'm doing naughty things like passing member-function-pointers around; but alas, they all worked.


Thank you all for the input!

[wysota]

I didn't ever call hide on my main window.. but maybe something about this being a modal dialog (thusly pushing the other back) counts as hidden.. or something.

No, it doesn't. If a window is hidden then something has called hide() or close() on it.

[amleto]

No, it doesn't. If a window is hidden then something has called hide() or close() on it.

or it was never shown...