beginUndo() not found in Script IDE only?

cwichura

While working on a script, I've noticed that beginUndo() causes the IDE to report exception: cant find variable: beginUndo() when I try to step through the script. If I simply execute the script, however, it works fine and the undo stack has the expected changes. In this particular script, I don't do much between beginUndo() and acceptUndo(), but it's still been annoying to have the Script IDE fail at this point.

What is the trick to make beginUndo() work properly in the script IDE?

Psuedo-code of where it fails:

if (allGood) {
  beginUndo()
  oNode.set...
  acceptUndo("Undo operation")
}

Thanks

rbtwhiz

For the benefit those reading that may be new to scripting and/or have not picked up on the "step through" reference... Although cwichura doesn't state so explicitly, this is an implicit reference to running the script under the debugger.

The sample below works as expected when executed normally in the Script IDE, or via file...

var oNode = Scene.getPrimarySelection();
if( oNode ){
 beginUndo();
 oNode.setWSPos( new DzVec3( 0, 10, 0 ) );
 acceptUndo( qsTr("Move Selected Node") );
} 

... but throws a ReferenceError when run under the debugger, in the Script IDE pane. This is presumably because the Global context for the debugger isn't being setup correctly - still investigating why. The sample below, with the offending Global methods wrapped in a try...catch block, will allow the debugger to continue stepping through the rest of the script.

var oNode = Scene.getPrimarySelection();
if( oNode ){
 try {
  beginUndo();
 } catch( error ){
  print( error );
 }
 
 oNode.setWSPos( new DzVec3( 0, 10, 0 ) );
 
 try {
  acceptUndo( qsTr("Move Selected Node") );
 } catch( error ){
  print( error );
 }
}

-Rob

cwichura

Thanks for the update, Rob. Hopefully tracking down why the global context is acting differently in the debugger won't be too hard to find. :)

DraagonStorm

While beginUndo() is not critical to running a script....

I'm getting ReferenceError: Can't find variable: getScriptFileName with:

var g_oFILE = new DzFile( getScriptFileName() );

Which the wrap in try will not work as I need to know where my script is being called from since I then in turn call some .duf files in the same folder or sub folders.

I'm assuming this is the same issue/problem.

rbtwhiz

Just a quick note to say that I've fixed the global context issue with the debugger. I've also taken the opportunity to spruce up the debugger a little - better use of space and some additional functionality. I would like to do more, but I have more pressing matters to tend to... so it'll have to do for now.

With the fix, the getScriptFileName() global function will no longer produce a ReferenceError when run under the debugger... but it doesn't change the fact that the function does not return the path of a file when run within the IDE. That is a separate issue.

-Rob

cwichura

Great to hear, Rob.

While it's a more general issue with the way Studio confines all sub-windows to one master Window, my biggest complaint when using the Script IDE from a space/etc usage is that I'd dearly love to tear the window out of the main Studio window and move it over to a separate monitor... But that's a pretty big paradigm shift for how Studio currently manages its windows and no doubt a non-trivial project.

Richard Haseltine

I don't have any trouble undocking the ScriptIDE and moving it outside the main application window - I don't, however, have a second monitor to try that.

rbtwhiz

There is nothing stopping you from undocking the Script IDE pane and moving it to another monitor (unless, of course, you have the action that locks docking/undocking toggled: Window > Workspace > Lock Docking/Undocking)...

Simply click and drag the pane's tab into the viewport, or right click on the pane's tab and choose Close Pane, followed by Window > Workspace > Panes (Tabs) > Script IDE. Both will create an undocked pane group with the Script IDE pane in it. Then you simply click and drag the pane group header to the other monitor and resize using the boarders of the pane group.

It's been that way for years.

-Rob