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

[Paul A Norman]

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
names) paths.

Then call from the Tw Menu Scripts/Js Trials/scriptIncludes.js

It runs these two function calls:

   alert(first_consts.lib_trial_hello);
	
   alert(first_consts.lib_trial_goodbye);

Yes, alert()    ;)

Paul

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?
>
> Paul
>
> 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?
>>
>>             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
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scripts-library-concept.zip
Type: application/zip
Size: 3889 bytes
Desc: not available
URL: <http://tug.org/pipermail/texworks/attachments/20100425/41e0b5a6/attachment-0001.zip>