Tired of the global scope (or lack thereof) and copying code to each activity so, I decided to xperiment with libraries. I've experimented with eval() and panel labels but it has limitations and just doesn't seem to be they way I want to go.

I created a simple libary files with one of my Toggle functions in it. I put the file - foo.js - in the Philip\librairy directory, shut down and opend pep and I cannot see the file in the building blocks.

The import/export function is looking .gef files and I believe those are created by PEP and so, a catch 22.

What am I missing?

thanks,

That is correct. You won't see your .js files unless you put a comment like is in the Philips unprotected libraries at the top. i.e. the comment is metadata that tells PEP what the file is. :-)

What are the limitations with eval() that you are experiencing? You can declare classes/functions/variables, etc... just fine if you utilize the undocumented eval() member function of Object. FYI, Activities, Pages, and Widgets are all Javascript Objects in that these classes use prototype inheritance from the base Javascript Object class.

Instead of using:
eval(mylabel);

use:

CF.activity().eval(mylabel);

which causes the activity scope to be the root scope for the eval.

If you use eval(mylabel) standalone, the scope that is used is not accessible unless you return it using "this;" as the last statement of script block (see usage of c being returned below).

So, consider this label content:

var a = 125;
var b = 234;
var c = {};
c.a = a;
c.b = b;
c; // this last line causes the object inside 'c' to be returned as result of eval.

If you then execute:
var d = eval(labelcontent);

d will contain an object with member fields a and b.

However, if you execute:

var d = CF.activity().eval(labelcontent);

and then do a toSource() on the activity as in:

CF.activity().toSource();

I believe you will see the member fields a, b, c, and of course d.

Note that eval() as a member function of an object (scope in this case) is not well documented and it is not documented in Flanagan or on the web but the current JS interpreter (Spidermonkey) allows this to work just fine.

Good luck and maybe you could edit the subject of your post to state something like:
"Libraries - Are they just .js files? - Advanced use of eval()".

Thanks
Lyndel

A library has to have a comment block at the beginning (nothing before it):

/*!
@title com.your.library.name
@version 0.1
@author Your Name
*/

Then you'll see it in the building blocks.

Lyndel the biggest limit of eval is that you have to update the label that is containing the code. With the libraries you just edit the library .js and it's done. (I frequently forget to use the reload from file button, let alone to update a label with code :). And Crockford says: eval is evil :).

Thanks for the comment block info. I'll give it a shot.
As for managing the libraries, each time the .js is edited does it require PEP shut down and restart to pick up the changes?

My use for Libs, now, are to make simple functions that I use more readily available with just a function call. e.g.

toggleButton(a,b,c,d...)

where the parameters passed are the booloean value for the button, the text to display when true/false, color(s) for the text...etc.

Sometimes the text is on/off (default) and sometimes it's more specific like "Zone 2 On", "Zone 2 Off" ...etc.

Other functions display small icon status indicators for remote zones.

Also, I'd like to have one and only one function to turn equipment on/off so that the states are managed properly.

I should have said that libs seem more straightforward for me instead of using the term "limitation."

Nope, just save the file in the appropriate folder, and PEP will pick it up automatically.

Well, there are indeed some considerations. But, Crockford obviously does not write code for the Pronto. If you need dynamic compilation, it is the only way to accomplish this.

Once upon a time, Barry Gordon's script extraction tool would handle panel labels with script. Never used it that much but I do know it worked.

Note that in PEPv2, as labels are unicode, that will also limit your script block size to 32KB. As a result, I started using JS compression tools that would strip comments and the like so I could pack as much as possible in there. And, on another note, if you use this approach, your script is not protected and available in clear text. If this is a concern, you should be using .pjs files as well.

Hi all

I've created a template library as a start for building your own library.

I'm travelling until friday, but i can post it here on fiday if someone is interested.