Loading...
> >

Programming a non-blocking window in DAZ?

chromchrom Posts: 261
in Technical Help (nuts n bolts)

Hi,

I want to program a window in DAZ so that my window with its buttons, ... can be used and also other DAZ components while my window is open.

DzBasicDialog seems to block the rest of DAZ until it is closed.

Do I need another widget or  pane or to configure DzBasicDialog?

 

Is there anywhere a simple sample for such a window perhaps also with communication to DAZ elements outside the window (signal, connect, slot)?

Comments

  • Richard HaseltineRichard Haseltine Posts: 109,821

    Although it is possible to write non-modal scripts it's not ideal, and possibly not suitable at all. The panes you see in the UI are all binary plug-ins developed with the SDK, not scripts at all.

  • kenshaw011267kenshaw011267 Posts: 3,805

    That's the default behavior of dialogs generally. I'm guessing that DzBasicDialog inherits from QDialog in Qt which has a member mode bool which controls whether a dialog is modal or modeless.

    But based on my limited fiddling with the API I think DzPane is more what you need.

    Signals and slots are Qt stuff. Any Qt documentation should help with that. In short a signal is a notification that some event has occured, such as the Apply button in a dialog has been pressed. Slots are ways objects can respond to signals.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 3,307

    You could try hacking one of the SDK examples and call QDialog::show() instead of QDialog::exec() to display the dialog. But without any documentation on the Daz Studio threading model, what is thread safe and what is not, what is reentrant and what is not, how to serialize concurrent areas, things are bound to go wrong in very frustrating ways. But depending on what you're trying to do, it might work. I think the Scene Info example shows a non modal dialog, but it only does one simple thing.

    It's very frustrating that Daz gives us a fairly powerful SDK, and then extremely subpar documentation that would allow one to really exploit it.

  • kenshaw011267kenshaw011267 Posts: 3,805

    At least they followed a coding standard and documented every function call at least a little. I've opened Doxygen docs for an API and found not a word of explanation or anything beyond the automatically generated info from Doxygen.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 3,307
    kenshaw011267 said:

    At least they followed a coding standard and documented every function call at least a little. I've opened Doxygen docs for an API and found not a word of explanation or anything beyond the automatically generated info from Doxygen.

    It's just really frustraing to have an actual in-proc SDK that can do just about anything, just to be hobbled by the fact that there's so much more to how an app works than just its method signatures. Especially when most of them are of the less-than-helpful form:

    void Foo::getX() // gets the X

    I had some pretty ambitious project ideas to conform Daz Studio to my workflow that I eventually had to abandon because I just couldn't guess reverse engineer how something relatively simple worked. And I'm not talking about anything that could be considered IP like HD morphs or autofit. Basic things that could work in one of many ways, that are just complicated enough to confuse someone trying to infer how it works by pulling levers. You're a dev too; tell me that's not the worst feeling in the world :)

  • chromchrom Posts: 261
    edited January 2020

    Thank you for the answers.

     

    I already walk through QT pages which are linked in DAZ API.

    But it is a hard thing to start and estimate what is the right to choose.

     

    Here to estimate what I want is a window to

    - display current viewport's cam name

    - walk through viewport's cam list by buttons (with a hint to Richards script)

    - set current viewport's cam visibility on/off by buttons

    - nice but not needed: switching current cam in viewport directly is recognized in my window (signals, ...)

     

    It's nothing wild but I assumed / wish that I can use DAZ UI when window is open - eg to change cam's position.

     

    Corresponding to this perhaps you can give a hint which widget, construct , ... I should /can use.

    - DzBasicDialog mode bool

    - QDialog::show()

    - ...

     

    Perhaps panes is like shooting with canons on sparrows.

     

    EDIT:

    I don't need a dialog - the bottom features of the widget. But it was the only one I found which looks like a container for a Label and buttons.

     

     

    Post edited by chrom on
  • kenshaw011267kenshaw011267 Posts: 3,805

    Dialogs are usually the simplest for putting buttons and the like, although any window can have such put on them.

  • garrettg11garrettg11 Posts: 53

    ManFriday's Turbo Content is the only thing I've run across so far that is able to keep an open child window going without going modal on the daz window. Its pretty awesome just for that fact alone, and being able to dig in your content from multiple places at once. And you can have more than one of them open at the same time even.

    https://www.daz3d.com/turbo-content

     

    I've been wondering the same question as the OP. Would be great to find some sdk documentation on that. 

  • garrettg11garrettg11 Posts: 53

    this might help you, I haven't had the time to dig, since I have to many projects going

    https://www.daz3d.com/daz-studio-4-5-sdk

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 3,307

    Doesn't the SceneInfoPane SDK example do something like this? And for all of that functionality, couldn't you assign hotkeys to certain code in your DLL to cycle through the cameras? It doesn't sound like you need a Dialog for this at all.

  • chromchrom Posts: 261
    edited January 2020

    sdk, dll, c++ sounds like an other and deeper way of programming. I hoped to build this simple features in an easy way. Until now I have only code for the IDE and assume it will be a dsa file and not a dll.

     

    ManFriday's Turbo Content : Because of " The plugin is for Windows 64 bits only." I guess ManFriday's Turbo Content is not a dsa script which can be reverse engineered to get  non-modal knowledge, or?

     

    I read some DZ and Qt regarding your hints.

    show seems also to be modal without explicit change of modal variable.

    ("show " close window immidetially without code after it and blocks everything when using a for-loop after it. )

     

    I tried to change modal but get this error:

     

    (function(){

    …

            var wDlg = new DzBasicDialog();

    …

            wDlg.setModal(false);

            wDlg.show();

            for ( var n = 0 ; n < 10000; n++ ) {

                    print( n.toString() );

            }

    })();

     

     

    Script Error: Line 74

    TypeError: Result of expression 'wDlg.setModal' [undefined] is not a function.

    Stack Trace: ()@:74

     

    Post edited by chrom on
  • kenshaw011267kenshaw011267 Posts: 3,805

    QDialog::show() relies on the status of QDialog::modal. it is false by default so it would be modeless by default. 

    DzBasicDialog does have a setModal since it does derive from QDialog (I just checked the header).

    I have no idea what you've done wrong but likely the basic issue is the SDK is for c++ so if you're not coding in it...

Sign In or Register to comment.