This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
execute command can be used in place of pcommand because it is easier to dohttp://czb.dcmembers...help/FARR#setUserVar => with object as value
pcommand execute plugins["JScalc"].myfunc(param1, param2);
then to handle pcommand in setstrvalue by yourself
Community-updated plugin-API documentation - with links to sample code-ewemoa (December 18, 2008, 01:32 AM)
A couple of things:1) Yes surely it can. What I would suggest you or anyone else to do is to make some fancy html template which I can implement
1) can another line be added to each item in the fssc list which shows author info and web page link? Maybe also a line with sample usage? or these can all be combined into the description field.
2) when an fsubscript script is disabled, it probably shouldnt show up in the aplugins list
3) i think the settings stuff and the script listing/disabling should be part of the official fscript release when it goes final -- no point in not having this amazing functionality.
4) i think in aplugins list, there should be some indication of which items are fsubscript scripts vs. standalone plugins.
5) double clicking an fsubscript script in the aplugins list should bring up fssc i think.
I would also like to start bundling f(sub)script into the farr releases -- there is absolutely no reason anyone should have to live without this.-mouser (December 04, 2008, 08:25 PM)
On a side note, I get something about: plugin CZB_FSubScript_extension_pack has failed on init-ewemoa (December 04, 2008, 08:26 PM)
BTW, czb, would you consider either removing...-ewemoa (December 04, 2008, 09:03 PM)
I thing I think czb could appreciate especially in his code is supplant() combined with factoring out a lot of those HTML and CSS fragments to files 
I think it'd be nice to have these (and perhaps others) but I'm not sure about whether they should be added via prototypes -- doing it that way seems like it would mess w/ global state so perhaps initially they could just be made available via a kind of "fake" namespace.-ewemoa (December 05, 2008, 05:07 AM)
|Application Name||CZB package|
|Short Description||Package containing all my FARR plugins released in the last year plus plugin management system and JScalc|
|Supported OSes||Limited by FARR|
|Web Page||not yet|
|Download Link||CZB pack: http://czb.dcmembers...ZB_pack/CZB_pack.zip|
|Download Link||FSubScript: http://czb.dcmembers...cript/FSubScript.zip|
|Author||Link to Author's Profile page|
onInit() onSetStrValue()Yes you are right, that it should be unified. I will leave all naming upon you so I will definitely change it into Init() and SetStrValue
I'm not so clear on how fscript.js/onSetStrValue() should behave -- specifically, the return value seems to get decided purely on whether a single sub-plugin returns true.
onInit() in the original fscript.js took a single parameter iirc, in the most recent code candidate the sub-plugin's onInit() doesn't take a parameter. I wonder whether mirroring the original interface is preferable or not. May be it's not a big deal. Any thoughts?I did it so because there is already curdir implementation via directory variable, so why to have it twice? So I would keep it without any parameter
I'm not sure about loading all fsubscript*.js files -- I wonder whether the loading order might matter in some cases and with the way the code is currently, a sub-plugin writer can only control this based on coming up with appropriate filenames. I hadn't really thought about multiple files per sub-plugin so I start to wonder about the potential consequences and alternative designs smiley
Inclusion of other files can be done with eval(getTextFile("json.js")) if your plugin is too big to practically work in one file.
I think sub-plugins should not extend global state. fsubscript could expose many useful functions so that plugin developers have less need for sharing things.