How to terminate a running script?

frits.vancampen

I'm looking at ways to terminate running scripts. Usually there is some keys you can press to terminate a running script (typically ctrl+c) but that doesn't work in Daz.

You can build in error triggers when the user clicks a cancel button on the render or load asset popup window but that doesn't seem to work right. Very often the 'click' is simply ignored.

And because of the focus-stealing 'bug' in popup windows I'm looking at starting Daz in -noPrompt mode, which works to prevent the focus stealing. It also disables all prompts so you've now gimped your instance so certain functions don't work right anymore. Why this is even a thing, I don't know, it's just Daz-logic I guess :shrug:

The documentation mentions there is such a thing as a background progress 'cancel' button. But where is this button? I've found the status bar where the progress is displayed, I see a text and a progress bar, but no button.

There is also this sample that provides a way to cancel a running process by detecting a keypress. This approach suffers from the same problem as the cancel button in popup windows where the click (in this case keypress) is simply ignored. This is probably because the application is doing something, so isn't ready to listen to user input. I haven't found a way to reliably get user input in Daz. In 'regular' JavaScript there is there event loop. Even if the script is busy, the event will eventually be handled. Clicking or pressing buttons cause an event. This is now how it works in Daz it seems.

So none of what I've described works. I can always force-quit Daz Studio but that hardly seems like a satisfying solution. Is there a feature that I'm missing? What is a good way to terminate a running script?

Richard Haseltine

The debugger can do it, though I can't recall the steps - but that isn't, as far as I could see, useful when the script is run from a file rather than the IDE.

DaremoK3

@frits.vancampen :

I ran into the same issue, and I am not sure if this will help you or not, but I resorted to writing a cancellation function for the process cancellation ('ESC') utilizing 'finishProgress()' to terminate the process inside the cancel function.  So, 'finishProgress()' for both process completion, and to force cancellation.

It seemed the only way to get the cancellation to actually work when pressing 'ESC', and immediately terminating the process.

Mind you, this was for cancellation of process in an open dialog, and not trying to cancel out of the dialog  --  Multiple usage for morph target deltas, and not just a single fire script.

Also, modified from this sample instead of the one you linked :  Progress Sample  --  http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/general_ui/progress/start

Richard Haseltine

Reading your post again, I think you should be looking at the SDK. A non-modal pop-up is a pane, not a dialogue box, and those are written using the SDK. For some purposes using Signals adn slots to trigger a script may work http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/language_reference/signals_slots/start - but you would not want to have a script running continuously in any event.

I'm not sure what you are wanting to do with the no-prompt feature, which is experimental, but its purpose is explained here http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/tech_articles/command_line_options/start - it sounds as if you may be wanting more than or other than it offers. Again, a plug-in written with the SDK may suit your aims better.

frits.vancampen

Thanks @DaremoK3 and Richard. I've looked at the things you mentioned.

I already looked at the `startProgress()/isProgressCancelled()` feature and I could definitly use the cancellation feature to send a stop signal. I haven't tested how well this works however because in my experience Daz Studio tends to ignore some clicks if the script is busy.

I've already implemented cancellation using `App.isKeySequenceDown()`, but effectively you have to hold down the key until the script passes that function. Which, in case of certain operations, may take a while (loading assets / rendering). Again, where is my event loop?  Maybe I could have one script start another script? Where the parent script listens to key presses and converts them to signals for the child script. Could be something to look into. 

I've looked at the SDK as well. That offers some additional features that scripting doesn't, such as the ability to make custom panes. That's not necessarily something I'm looking to do, but it might be worth exploring as a workaround for other roadblocks. By the way, why is making panes not available in the scripting evironment? Technical reasons?

I guess my biggest problem right now is that `App.getAssetIOMgr().doLoad()` steals focus, which means I can't use the computer while the script is doing it's various operations. Mainly because Daz Studio stealing focus makes doing anything else on the computer difficult, and Daz Studio will consume input that wasn't intended for it, eg. certain keypresses or holding down keys such as a CTRL. These keypress will mess up your script and likely cause it to exit prematurely.

So if there is another way of loading assets I would -love- to know about it.

To avoid this problem I've restorted to using -noprompt which is complete overkill but it 'works'. I ran my script for several hours yesterday while still being able to use the computer.

It's not clear to me wether using the SDK avoids this problem, since its API is the same as that available to scripting - with some added features. So that problem I suspect wont be solved by switching to the SDK. I could use the SDK to still allow some script control by making a custom pane, but I really hope I don't need to do that.

A major downside of using -noprompt is that `startProgress()` is no longer available to me, since it uses a modal popup, which counts as a prompt. So I've resorted to using `startBackgroundProgress()`, which the documentation says should present the user with a 'cancel' button, but I don't see where the button is. I haven't tested this, but I suspect that calling `startProgress()` will also steal focus, because the trigger for stealing focus seems to be opening a popup window so it's functionality is limited to me anyway.

but you would not want to have a script running continuously in any event

Oh you're giving me ideas Richard 

Richard Haseltine

Although a non-modal script is possible - there is at least one thread discussing this - it is strongly advised against. The scripting engine simply are not designed, as I understand it, to run continuously (and I would think this was an aspect of the Qt framework), which is why we have and need the SDK for certain features (new panes, new tools etc.).

It's certainly true that some operations do not process the event queue - e.g. the checking of spring lengths at the beginning of a dForce simulation - as the overhead for a well-behaved item would be excessive, for a benefit only sometimes, when a not well-behaved item was being processed. I cannot, however, say I have noticed DS stealing events from other applications when it has been stalled by a protracted, non-interuptable task.

frits.vancampen

The scripting engine simply are not designed, as I understand it, to run continuously (and I would think this was an aspect of the Qt framework), which is why we have and need the SDK for certain features (new panes, new tools etc.).

Ok, that makes sense. I do see some challenges if a script is allowed to make a pane. For instance what happens with the pane when the script exists? Should it be removed? I can understand not wanting to get into that.

I cannot, however, say I have noticed DS stealing events from other applications when it has been stalled by a protracted, non-interuptable task.

I can supply you with a straight forward reproduction case:

for (var i = 0; i < 10; i += 1) {	sleep(5000);	App.getAssetIOMgr().doLoad("C:/Daz 3D/Applications/Data/DAZ 3D/My DAZ 3D Library/People/Genesis 8 Male/Genesis 8 Basic Male.duf");}

Start this script. Then 'go do something else', for instance, focus the address field in your browser. Observe that after some time the address bar has lost its focus - the blinking cursor is gone.

If you minimize Daz Studio (if it will let you) then it 'only' steals focus. If you haven't explicitly minimized Daz Studio it will bring itself to the foreground.

Let me know if you can reproduce this. If you can't, that might be an avenue to explore if I can mitigate it on my side. There might be a difference between Mac and Windows, but in this case I don't expect to see a difference.

Also, maybe an additional challenge for you: how would you abort this script (if you didn't start it from the debugger)?

Richard Haseltine

Well, I used a different .duf file since my Genesis 8 is isntalled through connect - which would have made typing the correct path a pain. But running in the IDE at least I don't have any focus issues with DS sitting un-minimised in the background while typing this.

frits.vancampen

Ok, well that gives some hope. Is there any way we can compare Daz Studio settings/environment?

You do get the popup modal when you load an asset right? It just doesn't steal focus for you.

I poked around the menu a bit but I can't find any setting that seems to apply.

Richard Haseltine

Yes, I get the progress bar. The item I am loading is pretty small though, compared to a full figure, so if time is a factor that may be the reason.