GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Can the script addin system become corrupt?



Is it possible for the script addin system to become corrupted?

  • I am trying to set up a script config using tbone's system v1.2, which I have used very successfully before without any problems, but now simple changes in his sections of the .js file result in no change in the configuration screen, or missing lines, or a DOpus crash.

  • I'm also having trouble sizing columns from any script addin. The usual
    Set ColumnsToggle="scp:NameOfAddin/NameOfColumn(3)"
    works OK, but
    Set ColumnsToggle="scp:NameOfAddin/NameOfColumn(3,60)"
    almost always picks up the wrong column, often a column from a different scrip addin.

If something has become corrupted, perhaps deleting scriptconfig.oxc, and/or scriptcolumns.oxc, and/or others, from theConfigFiles directory would allow them to be rebuilt. Or maybe I should uninstall all addins and reinstall them.

On the matter of uninstalling a script addin, what is the recommended method of uninstalling an addin? First uncheck, then remove the file from the Script Addins directory? A few days ago, I had an addin hanging around on the list in Preferences even after the file had been removed, which may have been another indication of problems.

Scriptaddins.oxc corruption?
Problems with SortBy, and a script question

If I'd try to stick to official facts, I'd say no, but since I had situations like this as well, I dare to say "yes!". o)
I also experience crashes now and then, but these are not reproduceable, so it's hard to come back here and report.

Uninstalling and reinstalling all the script addins is worth a try, though I remember loosing all script configurations because of doing so - once at least. Did not do that again since then, it's not a pleasure to rebuild all folder formats using script columns etc. Just to be clear, I think Leo and Jon would be happy to fix anything that is needs fixing, but since these things happen so "out of nowhere" they are hard to track down for everyone.

Maybe it's something external that conflicts with DOs file handling? I run "Microsoft Security Essentials" and I have huge problems updating DO each time because of files being locked, still existent, access denied etc. I do not run UAC, full admin all the time and realtime protection in MSSE is disabled as well, still no way to update without hickups. Noticed this might be related to MSSE, because I installed it somewhere else and suddenly DO would start to struggle there as well when updating.


Delete it from the /dopusdata\Script Add-Ins folder.

I'm guessing whatever is happening is due to something getting in a confused state when editing active scripts a lot. Never seen it myself, but it's not something that many people do very often, so it's certainly plausible that there is still some kind of bug lurking in there.

Are there any crash dumps that match the date & time of the crashes you saw?


I've also had the kind of problems described here - and I think I've sent in crash dumps here and there for some of them, but I don't always get a crash. Sometimes I just have general instability inside Opus - file operations won't work, dbl-click does nothing, drag and drop stops working. I'm sure the different types of breakage may have something to do with the specifics of the script being worked on at the time.

To clean things up I've had to resort to keeping a regular batch file in my system path so I can just call up a cmd prompt and run it quickly, to do exactly what Leo suggested above. Then kill and restart the dopus process...


Most interesting — I'm encouraged that at least I wasn't doing totally ridiculous things. Now that the storm has passed over and I dare to plug in my computer again, I've emailed all the current minidumps to — as I said in the original post, the crashes and the config screen not showing changes or omitting lines all happened over the last couple of days when editing the details of tbone's config system. My previous constant live editing of this addin's functions and columns didn't cause any crashes.

The problems with being unable to specify addin column width, also described in the original post, has been around for months, with the same problem that the wrong columns appear, often from other, unrelated, script addins. Deleting scripts is not a problem at the moment.

To tbone's remarks: I am using Eset Smart Security 8.0.319.0, and so of course Microsoft Security Essentials is turned off (and I am still on Windows 7 Pro SP1).
To Steje's remarks: I'm not getting the other behaviours you describe, 'file operations won't work, dbl-click does nothing, drag and drop stops working'.

The question remains:

  • Can I delete scriptconfig.oxc, and/or scriptcolumns.oxc, and/or other files, from the ConfigFiles directory, and hope that DOpus can rebuild them?
  • Or should I uninstall and reinstall all my script addins?
  • Or (probably the best idea for now) should I just wait for further developments?


Look at what's in the config files to decide if there's anything in there you'd care about losing, or which looks out of place.


I removed the two .oxc files that I mentioned above, shut down DOpus and restarted, but the behaviour hasn't changed a lot.

  • Adding script columns with the width specified usually picks up the wrong column, often in another script.
  • Edit the text of the configuration sometimes crashes DOpus (but all four new minidump files this morning are empty, so there is nothing more to send in.)

I have now begun closing the Preferences window before every time I save the file, and so far no crashes have occurred with this procedure. So I will continue in this way, reckoning that DOpus is like me and can't think about two things at once.

I have no idea, however, what is going on with the scrip AddColumn command when a width is specified. Putting a default width into the script is an easy workaround, but the behaviour remains a puzzle.


I can tell, after having removed all the script addins and putting them back in place again yesterday, that DO did not get confused by this (talking about 95 addins). All columns and script configs are back in place and working. So, maybe just go for the same. Before putting scripts back to work, consider renaming the one you have problems with. DO will generate new internal IDs for new script names, which can straighten specific things. I sometimes need to rename script addins temporarily while messing with config items, it helps DO to recognize the changes. If you are really obsessed, I guess you can even try to track the column/script addin IDs assigned in the various config files of DO and find where the mixup happens. Just a thought. o)


Thanks for sending the crash dumps over. I've been looking at them and it's given us one potential area to look in, but nothing definite. It looks like something is corrupting the memory heap, so the crash happens when the next thing falls over the mess, not always when anything involved is still acting. But one of the crashes was in code for the script config dialog, which is interesting (but may be a coincidence).

If you can give any pointers on how to reproduce the problem, we'd like to give them a try. Preferably something along the lines of "start Opus, load a particular script, then make a particular edit" type steps so we can try the exact same things.

[quote]* I'm also having trouble sizing columns from any script addin. The usual
Set ColumnsToggle="scp:NameOfAddin/NameOfColumn(3)"
works OK, but
Set ColumnsToggle="scp:NameOfAddin/NameOfColumn(3,60)"
almost always picks up the wrong column, often a column from a different scrip addin.[/quote]

That seems to work OK here.

If details of script columns are changed while the columns are in use, it sometimes requires a restart of Opus for things to be updated, since some of the information gets cached. (Usually script column labels for the headings and things like that, in my experience.)


[nowrap][/nowrap]Thanks, leo. All I can do in response is to report as precisely as I can.

CRASHES: All the crashes occurred when I was working on the configuration of a script addin I am developing, and

  • the addin's Preferences configuration screen was open, and
  • the addin's script file was open in an editor, and I had just saved a change in the text on the left-hand side of the config screen.
    Doing this did not, however, always trigger a crash. Very, very roughly, it happened on 20-40% of occasions.

The crashes are not happening any more. First, I got clever and closed Preferences every time before I saved any changes. Secondly, I am no longer using the configuration procedures because as I said in a later posting, I don't think configuration applies to column names, and it certainly doesn't apply to column numbers. If I get any more crashes, I'll send in the minidumps.

COLUMN WIDTHS: Something is definitely wrong now and used not to be wrong. Another very specific example:

  • In a tabgroup, I have an "SC1" column from the "Custom Sort Column" addin that you wrote some time ago. This column is no longer the "SC1" column, but is now the "Days SM" column from "Column.General: ModifiedWithin".
  • I have a corresponding button that also used to work properly:
    Set ColumnsToggle="scp:Custom Sort Column/CS1(1,36)". This button now adds a column headed "Mark" from the script that I am preparing, and inserts the new column at the end of the columns. On the other hand:
    Set ColumnsToggle="scp:Custom Sort Column/CS1(1)"
    adds the correct column in the correct place. Easily fixed — I just added cmd.defwidth = "36px" to the "Custom Sort Column" script and deleted the width from the button. By the way, this behaviour was going on before I started composing the script addin — the first problems with wrong columns occurred after I installed "EMLEmailColumns" just after it was published, but I can't remember the details now.


I experienced the same problem today.

Preferences screen and script configuration screen were open. I changed a line that used tbone's function, something like:

From: cfg.add("playerOpenCommand", "", "Set the command to open specific player.);
To: cfg.add("playerOpenCommand", "", "Set the command to open specific player.\r\nExpected format: \"C:\\Player\\Player.exe\" \"%1\" Argument2 Argument3");

Then saved the script file. I can't remember exactly, but I think I then changed an option for the script, clicked OK to close the configuration window, then clicked apply on the Preferences screen.

That resulted on "a thread crashed". I clicked "try to continue". Then my profile was corrupted. I restored from a copy and it is okay now.

I am sending a mini dump for analysis.