Daz Script Debugger
Richard Penney
Posts: 41
I have a couple of basic questions concerning the Debugger.
I've been using it for a a few months now, but still can't find a way to kill the debugging session when I encounter errors. I know there's a Pause function, but that doesn't kill the process. If I run into a endless recurssive problem, I have to kill the Daz Studio app.
My other question has to do with the color of the line numbers while the Debugger is running. On my machine, the line numbers are a deep green over a black background, and are unreadable. I've tried setting colors in Preferences, but to no avail. Any suggestions?
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Yeah, I've had the same problem. There doesn't appear to be any way to terminate a script. Quite a few times I've had to close Daz and restart.
Thanks for the confirmation that I'm not losing it!
Regarding the line number colors, I can not understand why they decided to change the line numbers and background colors once you enter a debug session. Why not leave them alone. As far as I can see, the Script IDE Preferences doesn't support the colors displayed while debugging. Can anyone tell me I'm wrong about this? I hope I am.
That's the way it is ;-)
My biggest issue is that it cashes (at meast on OS X), if you do something with a DzWidget in the class constructor of your dialog handling object with an item not setup, usually when you copy code from one script into your script, who wants to write all ten lines to setup a decimalSlider every time?.
You copy the code, forget to change for example the name of the layout it's to be added to so it passed a non setup no existing member, Poof. Feels like being back in Mac OS 7 ,-)
Yes. The Debugger is not very forgiving when it encounters a variable (widget) that hasn't been defined. Actually, it's not the debugger, per se. The scripting engine will sometimes cash, so the best way to minimize those issues is to wrap your code in try/catch code.
If you find yourself reusing the same code a lot, consider building a library of widgets and function handlers. If you haven't done it before, simply include() the path of the library module at the top of your dialog code.
Yes, I've done some excepton handling andsome libraries for different things, but crashes are open typos (or copy/paste), you pass this.theGroupBix instead of this.theGroupBox...
Yeh, I do that a lot too. And stare at the bad line of code and not see the GroupBix typo for several minutes. Just part of life as a developer :-)
Lol, yes, but on OS X (don't know about Windows), it crashes DS if that like is executed.
Rob did flag this, but it ended up in spam - I apologise for the belated reply (especially as it was soemthing I thought was the case anyway). The debugger, unlike the script pane, is part of Qt and as such there is a very narrow limit to what Daz can do to it (just the exposed APIs) - see https://doc.qt.io/archives/qt-4.8/qtscriptdebugger-manual.html
Having read that, typing
.interrupt
into the console seems to stop execution and return cotnrol to DS.
Will very soon verify that ;-)
Richard, I was experimenting with typing in .interrupt into the console window, and it does return control to DS. It does not, however, terminate the debug session, so depending on the nature of the problem, it may not provide a solution.
I saw the .return console command, which states 'Make selected stack frame return to its caller'. It looked promissing, but when I enter the command, DS crashes. Couldn't figure out how to 'select a stack frame'.
I found that switching to another activity and then back again closed the debug window and reexposed the actual script - not sure if that's a bug or not, or in which, but if you are seeing something similar it does suggest it's a real behaviour (and if a similar fix works for you it might be soemthing Daz could address by adding a redraw signal somewhere).
I just found out that when you have a scripted dialog window displayed, you loose access to the Debugger's console window. If you had previously set a breakpoint somewhere inside the dialog code, that will return control to the Debugger and let you enter commands, such as .finish. That should return execution immediately after the dialog's exec() call.
I'm wondering if the SDK modeless dialogs will make these console commands more useful.