Qt dialog priority

davidnhutch

Hi,

I want to execute a dialog from a .ui file, that has a button that launches a BrowserDialog. So I followed your example here

I just replaced the code inside button.clicked block, so that it launches a BrowserDialog instead of moving the slider. However, on Win10 (and possibly other OSs) it does launch the browser but you can't click on it to read it or to close it -- because the primary dialog takes precedence. How to suppress this behavior so that you can interact with the BrowserDialog?

module QtCreatorDialog

  include RBA

  # Load the UI file
  # We use the sample file provided as resource
  ui_file = QFile.new(":/macro-templates/qt_designer.ui")
  ui_file.open(QIODevice::ReadOnly)
  dialog = QFormBuilder::new.load(ui_file, Application::instance.main_window)
  ui_file.close

  def dialog.setup
    button.clicked {
      RBA::BrowserDialog.new("Some text").exec
    }
  end

  dialog.setup
  dialog.exec  

end

davidnhutch

I should mention what I've tried. Several C++ solutions to this problem I've found online involve using .activateWindow, .raise, and/or .setFocus. I try all three inside button.clicked, but it doesn't work

  bd = RBA::BrowserDialog.new("Some text")
  bd.show
  bd.activateWindow
  #bd.raise # Raises an error - "can't use protected method 'raise'"
  bd.setFocus

Also, if not possible to have a 'child' RBA::BrowserDialog, then just getting it working for any 'child' QDialog is fine, but I have been unable to.

Matthias

Hi David,

The problem is easy to solve if you give the BrowserDialog a parent which is the dialog you call it from. Then there is a strict hierarchy of widgets and the priority is defined properly.

Unfortunately there is no parent argument to the constructor of BrowserDialog and setting the parent after the constructor is called does not have the desired effect (don't ask my why).

But the BrowserDialog's capabilities are not quite pronounced, so you may be able to emulate the functionality. Like this:

module QtCreatorDialog

  include RBA

  class NewBrowserDialog < QDialog

    include RBA

    def initialize(parent, text)
      super(parent)
      ly = QVBoxLayout.new(self)
      browser = QTextBrowser.new(self)
      browser.plainText = text
      ly.addWidget(browser)
      ly2 = QHBoxLayout.new(self)
      ly.addLayout(ly2)
      ok_button = QPushButton.new(self)
      ok_button.text = "Ok"
      ok_button.clicked { self.accept }
      ly2.addStretch
      ly2.addWidget(ok_button)
    end

  end

  # Load the UI file
  # We use the sample file provided as resource
  ui_file = QFile.new(":/macro-templates/qt_designer.ui")
  ui_file.open(QIODevice::ReadOnly)
  dialog = QFormBuilder::new.load(ui_file, Application::instance.main_window)
  ui_file.close

  def dialog.setup
    button.clicked {
      bd = NewBrowserDialog::new(self, "Some text")
      bd.exec
      bd.destroy  # release resources immediately
    }
  end

  dialog.setup
  dialog.exec  

end

Best regards,

Matthias

davidnhutch

Thanks Matthias, as always it works like a charm.

(Perhaps you saw the next question coming...): Why need to release resources immediately? Because I have never used the .destroy method for anything else, so would like to know when it is appropriate or needed.

Matthias

You guessed right, I saw it upcoming :-)

I got used to using destroy a little myself. Not out of necessity, but mainly because if there are issues connected to that, those will pop up then rather than being triggered at some arbitrary point in time later on when the garbage collector chooses to destroy the object.

Please keep in mind that destruction of the dialog object will destroy the child widgets too and we learned that there are some pitfalls related to that (although I am trying to improve robustness against side effects of the destructor). Since garbage collector related issues tend to be very difficult to reproduce and even more difficult to trace back, I think that making things a little more predicable is a good habit - but not a necessity.

Best regards,

Matthias