[texworks] Help please with Integer constants and use in messageboxes
Paul A Norman
paul.a.norman at gmail.com
Sun Apr 25 09:57:06 CEST 2010
Ok, here is one possible approach.
Was looking at wrapping the include into a function but running it
flat may be easier.
Two attached files unzip into the config directory with (use folder
Then call from the Tw Menu Scripts/Js Trials/scriptIncludes.js
It runs these two function calls:
Yes, alert() ;)
On 25 April 2010 15:23, Paul A Norman <paul.a.norman at gmail.com> wrote:
> P.S. I was thinking if ...
> "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."
> ... were possible - we could settle on some nomenculture and perhaps
> look at Json and named objects to avoid unnecessary conflicts?
> On 25 April 2010 15:12, Paul A Norman <paul.a.norman at gmail.com> wrote:
>> 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?
>> 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.
>> 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
>>> 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....
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3889 bytes
Desc: not available
More information about the texworks