As the saying goes, "An ounce of prevention is worth a pound of cure", so it is that putting some extra work into the construction of your script will make troubleshooting less likely to be needed. Make liberal use of methods like try: and if: to test the running conditions of the script, but equally important is that when these fail, give a useful message to the user. This is where a messageBox() can go a long way to helping the situation.
if scribus.selectionCount() == 0:
scribus.messageBox('Scribus - Usage Error',
"There is no object selected.\nPlease select a text frame and try again.",
scribus.ICON_WARNING, scribus.BUTTON_OK)
sys.exit(2)
If the script just quit or failed for some reason, the user might not have any idea what was wrong, but here he gets a specific message. Sometimes you may want to do this:
if scribus.haveDoc():
else:
scribus.messageBox('Usage Error', 'You need a Document open', icon=scribus.ICON_NONE, button1=scribus.BUTTON_OK)
sys.exit(2)
but as we saw in temp_graphing.py, you might do this:
if scribus.haveDoc():
else:
if scribus.newDocument(scribus.PAPER_LETTER, (20,20,20,20), scribus.LANDSCAPE, 1, scribus.UNIT_POINTS, scribus.PAGE_1, 0, 1):
scribus.messageBox('Message', 'You did not have a document open, so \none has been created for you.\n\nNow you can run the script again.', scribus.ICON_NONE, scribus.BUTTON_OK)
where you not only identify the issue, you also do something to help resolve it. Often, when you can't figure out what's going on, you can temporarily insert a messageBox() to give you some feedback. Here is something I had in my initial versions of temp_graphing.py, just after the importing of 24 hour data from the file:
scribus.messageBox('Your Data','Your data has '+str(i)+' data points', scribus.BUTTON_OK)
so that already at this time I had a warning of a flaw in the data file, if there was some number of data points other than 24. Something else I noticed in this script was that, in spite of intentions, the graph tick marks did not fill up the Y axis. When I put in a messageBox() to inspect the scaling value, I realized that I needed to create this as a float() value, or it would be represented as an integer.
We all make typographical errors as we type, and these are very troublesome in scripts. If you are lucky, you may get a syntax error message, but often there is some feedback that just doesn't make sense. In many of these cases, noting the line number identified as a problem is your best clue. Go there and see if you've forgotten a closing parenthesis, or put in too many, or maybe just spelled something wrong. As I said in the beginning, Python is very picky about indentations, and expects all the lines in a given section to line up with each other. This is where using an editor that has features to help coding is very useful. I use Kwrite, sometimes Emacs, and both of these automatically will do syntax highlighting of keywords, and manage indentations well, but what triggers this is that each must know that the file that is being edited is a Python script, because its name ends with .py.
The last piece of advice I would give is to make your scripts in an incremental way. Especially with all the error-checking that is more or less routine, I often begin with some script that I know works contains all of that, and strip it down to nothing but the error-checking, then begin to assemble the new tasks one at a time, periodically running them in Scribus to make sure I haven't broken something. This is especially important when I am using commands that I haven't used before, or use rarely. Sometimes, when you're adding some new feature to an already sizeable script, you have to pull out the new feature into a new, small one to just work on that aspect. This also means that you should keep scripts that aren't so useful anymore, and also that all your scripts contain comments that help you understand them years later. Don't forget to try out some old script to make sure that it still works. Over the years, there have been various changes in the Scripter commands, especially with parameters that are required. Many constants have changed.
There are a number of things you might have in a script that are not specific to Scripter, and therefore might be most easily worked out in some Python script that you run outside of Scribus.
Ultimately, you have to have a mindset that keeps you persistent at scripting.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.