Script dialog open. Tried accessing script prefs - unresponsive. closed script dialog - crash.
id #324 (edit: incorrectly said 134 before)
Thanks, hopefully fixed in 13.7.5.
Has not crashed, but the unresponsive script config button is still happening, not sure what is causing it. Happens when testing OnScriptConfigChange event routines and script dialog is always open and script editor and after quite a few changes to the scripts config.
Please post a script (if possible, with minimal code needed to reproduce the problem) and tell us what to do to reproduce the problem.
Background Changer.opusscriptinstall (6.7 KB)
(do not use - in progress - for testing purposes only)
make button with the command
BackgroundChanger
this will turn the slideshow on/off
using the default folder (Windows 11 theme folder) or put another path in script prefs.
optional
put some images in a folder.
make a button with command
BackgroundChanger PATH="C:\My Image Folder"
this will not turn off unless the first button is clicked.
(allows quickly switching folders using a FOLDERCONTENT menu)
keep scripts dialog open
change logging pref to on (any level)
have Log Panel showing
click button to start slideshow mode
- change a pref - like display mode
- press ok
do this a few times
and usually the scripts prefs button (the cog) will become unresponsive, when this happens and the scripts dialog is closed then sometimes it is not possible to re-open it - a restart solves all problems.
UPDATE: have tried to track what is happening and found that the offending code is in OnScriptConfigChange() and happens only when the slideshow is running.
If the rerun BackgroundChanger commands are commented out then the script carries on normally and the bug does not happen - but the new values that have been changed are not being used by the currently running instance. The slideshow has to be manually stopped and started again for the config changes to take effect.
Which is essentially what the rerun commands are doing, except they are doing it from within the script and causing the Script Config button (the cog) to become unresponsive.
UPDATE: stopping the slideshow normally, using the the first button fixes the problem - the script config button starts working.
Have you considered using a more suitable timer?
Like a hidden dialog (available in the latest betas) that manages the timer.
Your current implementation, is basically choking DO and your computer (specially noticeable when logging something)
Not sure how to do it another way. Please feel free to ammend the code and post it here and I will have a look at it (hopefully learn something from it).
Only stutters I have encountered have been from the fade transition.
Yes, the way you’re doing things is going to cause problems. Use a (hidden) dialog and timer instead of calling Delay and having the script method block for long periods (which can block the script from doing other things).
My mistake, the term we've used is "message-only dialog", set via the MsgOnly property which was added in 13.7.1.
Have switched to using invisible dialog timer.
Many thanks for advice.
The original problem (unresponsive script config button) is still happening as detailed above.
If you can provide a minimal script that demonstrates the problem, we can take a look. The script above is almost 1000 lines and full of things that don't look relevant to the problem.
Made a small script up, cannot reproduce the error.
with the posted script
- can change script config one time if slideshow is running
- stopping the slideshow resolves the problem
It's because your OnScriptConfigChange runs a command (its own script command) which never returns. The script dialog is waiting for your OnScriptConfigChange method to return before it'll let another config dialog open, but it never does.
You should use Command.SetModifier("async", true); to run the function asynchronously.
1 Like
Many thanks for looking into this, makes sense now.
Though using
cmd.SetModifier("async", true);
in the OnScriptConfigChange function, (before call to rerun the command) is causing an error.
command object is being created using
DOpus.Create().Command;
using
command = '@async:BackgroundChanger';
brings up a windows 'cannot find' dialog.
code
// Called whenever the user modifies the script's configuration
function OnScriptConfigChange(configChangeData)
{
log(1, ' ');
log(1, 'OnScriptConfigChange');
/* THIS FUNCTION IS FOR UPDATING THE RUNNING SLIDESHOW WHEN PREFS ARE CHANGED
BUT WHEN SCRIPT PREFS CHANGED A SECOND TIME
THE SCRIPT PREFS COG BUTTON BECOMES UNRESPONSIVE BECAUSE THE FIRST
OnScriptConfigChange EVENT HAS NOT RETURNED
- SEE https://resource.dopus.com/t/script-dialog-unresponsive/51661/13 */
/*
// check if running
if (DOpus.vars.Exists('session_backgroundchanger_toggle'))
{
log(1, 'Script Config Changed - toggle exists');
if (DOpus.vars.Get('session_backgroundchanger_toggle'))
{
log(1, 'Script Config Changed - toggle is on (slideshow is running)');
// close running instance
DOpus.vars.Set('session_backgroundchanger_toggle', false);
DOpus.SendCustomMsg('canceltimer');
// delay here to wait for the running instance to register cancel message
DOpus.Delay(500);
// rerun command
if (DOpus.vars.Exists('persist_backgroundchanger_imagesPath'))
{
if (DOpus.vars.Get('persist_backgroundchanger_imagesPath') == Script.config['Path to images'])
{
// run normal mode
//cmd.SetModifier("async", true);
command = 'BackgroundChanger';
cmd.AddLine(command);
cmd.Run();
}
else
{
// run arg mode
//cmd.SetModifier("async", true);
command = 'BackgroundChanger ' + 'PATH=' + '"' + DOpus.vars.Get('persist_backgroundchanger_imagesPath') + '"';
cmd.AddLine(command);
cmd.Run();
}
}
else
{
log(1, 'Script Config Changed - persist_backgroundchanger_imagesPath does not exist');
}
}
else
{
log(1, 'Script Config Changed - toggle is off (slideshow not running)');
}
}
else
{
log(1, 'Script Config Changed - toggle does not exist (slideshow not running)');
}
*/
return;
}
Can we see the new OnScriptConfigChange code? The description of the changes is useful but may miss important details.
its' above, commented out under the first comment.
That's for adding that.
Looks like @async: doesn't work before commands when run via scripts, but we'll add a way to do that in the next beta.