[texworks] Help please with Integer constants and use in messageboxes

[Paul A Norman]

Dear Jonathan and Stefan,

Thanks to you both for answering these things it is truely really appreciated.

I was thinking of changing all my scripts to explicitily do what is
intended rather than relying on any "current behaviour" in case you
did just what you are saying Jonathan.

I can already see that some of my earlier scripts may not work under
recent improvements like \n working now where I was previously looking
for the unicode usage. This happend ot my itemList.js script that
produces a list environmentm using the drop down box dialogue to
choose the environment type.

I am in the middle of a writing project and simply make scripts when I
need something and share any of the generic ones on Stefan's Script
261 Issue http://code.google.com/p/texworks/issues/detail?id=261&can=5
in case they are useful to any one else, or a base for imporvements on
what I have done.

On the constants, are we able to run another QTScript from QTScript? I
noticed a command that looked promising but was not sure what to pass
to it as it was looking for an object not a string filepath?

             TW.target.runScript(QObject*)

If so would variables in a header script run first be available to the
calling script, or would they pass from scope/memory when the script
called script finished?

If such constants or even functions could be loaded in like this, I
was thinking that I would be prepared bit by bit to try and make up
the constants lists as things came a long (dialogues etc) so that
there could be a library perhaps of useful scripts that could be
called for QTScript, and if any one else wanted to adapt them for .py
and .lua there would be a starting point hopefully easily altered.

Paul

On 24 April 2010 23:49, Jonathan Kew <jfkthame at googlemail.com> wrote:
> On 24 Apr 2010, at 12:36, Paul A Norman wrote:
>
>> I have found that the messagebox with 1024 can be suppressed by
>> setting its result to null as below.
>>
>> Should I be setting the result of the script to null?
>>
>
> Currently, the return value of the script (if not null) gets displayed by texworks in a dialog; and an assignment statement returns the value being assigned, hence the behavior you see.
>
> (This was originally the simplest/only way for a script to display something to the user - e.g. imagine a word-count script that wants to display its result.)
>
> To suppress this, I usually just use the line
>
>  undefined;
>
> at the end of the script; this (obviously) evaluates to a null value and so no message is displayed.
>
> Now that we have various ways for scripts to present messages, though, I'm thinking that using the script result as a way to display something to the user isn't really needed, and it is often a nuisance. So perhaps this will change (which would mean that existing scripts that INTEND to display a result by returning it will have to be changed to use TW.information or similar).
>
> Any thoughts on this would be welcome....
>
> JK
>
>
>
>