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

Paul A Norman paul.a.norman at gmail.com
Sun Apr 25 11:12:09 CEST 2010


Recomend this type of approach in the preamble

Paul
/////////////////////////////  Begin Preamble  \\\\\\\\\\\\\\\\\\\\\\\\\
	
function getLibrary(libraryName)
{
  var libraryPath;

  var scriptsHere = __FILE__.lastIndexOf("/scripts/");
     libraryPath = __FILE__.substr(0,scriptsHere) + "/scripts-library/";
		
		 //   /script-library/ is a sibling to /scripts/ just below /config/
		 		
	var thisLibrary = libraryPath + libraryName +".js";
	    thisLibrary = thisLibrary.replace(/\//g, '\\'); //MS Windows Specific
			
			
	var libraryOpened = 	TW.app.openFile(thisLibrary);
  var Js = libraryOpened.text
			  libraryOpened.close();
			libraryOpened = null;
	return(Js);
	}	
			
 // sucessive libaries can be called this way.			
			
		eval(getLibrary("const_hello"));
	// e.g.  	eval(getLibrary("const_second"));	

/////////////////////////////  End Preamble  \\\\\\\\\\\\\\\\\\\\\\\\\

On 25 April 2010 19:57, Paul A Norman <paul.a.norman at gmail.com> wrote:
> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>
>



More information about the texworks mailing list