I am trying to use a dockControl with a PySide UI that uses a ScriptJob to update aspects of the UI.
I am running into problems getting the scriptJob to die when the UI is closed - the scriptjob is persisting.
I’ve tried parenting the scriptJob to the dockControl - doesn’t work.
I’ve tried killing the scriptjob when the QMainWindow is closed through the closeEvent, but the closeEvent is not triggered when the dockControl is closed.
I am using Maya 2014 sp3. Any advice?
are you actually deleting the UI or just hiding it? As a backup, you can have the scriptJob check for the continued existence of the GUI item each time it fires and gracefully suicide if the widget is no longer alive, but that’s ugly. That’s supposed to be what parenting is for… hmm…
I am using the Close Button on the DockControl widget title bar. It doesn’t seem to be triggering the close event on the QMainWindow that is set as the content of the dockControl.
this seems to be the answer… dockControls only hide themselves when you click the X button to close them
http://mayastation.typepad.com/maya-station/2010/08/dockcontrol-part-2-adv-usage-1.html
So you could probably just hook the panel’s visibleChangeCommand to delete it as needed
boy this dockControls are a pain in the a**!!
apparently the visibility changed command is triggered when the dockControls floating status is changed. For a split second the dockControl thinks it is obscured and triggers deletion! grrrr…
So Floating and Docking dockControls triggers multiple visibilityChanged triggers. Floating a dockControl causes two visibility triggers and docking a floating control triggers three.
I guess I’ll need some sort of external monitor of the dockControl to determine after it’s finished changing state whether or not to really delete it…
does docControl have the ‘managed’ flag?
it does have the managed flag…go on…
Check and see if the managed state changes when the visible changes. I think it won’t, so you can use that as a break on temporary deletion.
Hey guys, I just happened to stumble upon this thread while trying to solve the exact problem you guys were talking about above. I can’t seem to use the visibleChangeCommand flag to determine when to delete the dockControl because it is deleting it when changing docking states as well. Just wondered if you found a solution to this problem? Did using the managed state flag help in some way?
I originally planned on using the script job to save the window state, but since I was using Qt to populate the dock control, I ended up going with QSettings.
Oh, nice. I never thought about using QSettings. Were you able to solve deleting the dockControl? This issue I think I’m running into is that when hitting the ‘x’ on the dockControl, it’s just hiding the control and not deleting it. I would like to be able to delete the dockControl and it’s content, a QMainWindow, but I haven’t been able to. I tried doing a check to see if it was visible then using deleteUI in an executeDeferred but it causes Maya to crash.
if pm.dockControl('dockControl', query=True, visible=True):
pmUt.executeDeferred(pm.deleteUI('dockControl'))
I gave up trying to delete the UI when the control is hidden. I just adapted my functions to save the UI settings on close or hide.
I can see why. It is being a huge pain for me right now. I also gave up deleting the dockControl and just focused on making sure I was saving the settings (writing out to an XML file) but I still am having problems trying to find a reliable way to always make sure the settings are being saved. As far as I could tell the QMainMenu’s closeEvent and del were not being called anymore when it was part of the dockControl. So I’m not sure exactly how you set your stuff up to work on close or hide? Also, I started seeing weird behavior with the dockControl such as when typing in a QLineEdit, if I tried to type D (shift+d) Maya would try a duplicate and throw and error saying I had nothing selected. It was like the QLineEdit wasn’t getting focus or something. Did you encounter any problems like that?
here are some excerpts
self.dockCtrl = cmds.dockControl(aa=['right', 'left'], a='right',
content=self.objectName(), w=370,
vcc=lambda *args: self.saveSettingsWhenHidden(),
label='My Tool Box')
and
def saveSettingsWhenHidden(self):
if cmds.dockControl(self.dockCtrl, q=True, io=True):
self.writeSettings()
i’ve used a dock control from robg and jam my own qt widget in there. I use the onHide method to save settings and i believe that will actually get called if you just close maya. As for your shift+d issue, that happens because maya’s viewport want to steal focus. I think someone metnioned it was to fix some other bug. The way around it is to use a subclass of QLineEdit and override onKeyPressed and if the modifies is Shift, then accept so it doesnt bubble to maya. I havent seen any adverse problems with this:
class LineEdit(QtGui.QLineEdit):
def keyPressEvent(self, event):
if event.key() in (QtCore.Qt.Key.Key_Shift, QtCore.Qt.Key.Key_Control):
event.accept()
else:
super(LineEdit, self).keyPressEvent(event)
Thanks! I’ll give that a try. I was using the visible flag instead of isObscured. As for the input weirdness, have you or anyone else here had any trouble with Maya picking up typing as hotkey input on a QLineEdit? It’s weird because I never once had it happen before using a dockControl. I have been using my normal PySide Qt tools and never had an issue. Then after putting the same tool inside a dockControl I started having problems. Just wondering if I missed something or a step somewhere? I just set the content of the dockControl directly to my QMainWindow.
Thanks Maxx, I didn’t refresh the page until after I posted so I didn’t see your answer until after typing the above. Are you just overriding the onHide method for the QWidget or actually overriding something on the dockControl. I didn’t have much luck getting direct access to whatever UI element the dockControl actually creates. Where exactly is the onHide command you are overriding? I see the QWidgets have a hide() method, but that didn’t seem to work.
yeah, onHide on the qwidget i jam in there. Once i get it wrapped, i don’t really care about the cmds side of things
That worked really well. Thanks! Only issue I’m seeing now is that it doesn’t seem like the hide method is getting called when Maya closes. So assuming the user always has the tool open, makes a bunch of changes, then closes Maya without ever hiding it, nothing would get saved. Any suggestion there? I was looking for something similar to the hideEvent() method but for deletion but all I found was delete() which I assume is probably not safe to override.