DonationCoder.com Software > FARR Plugins and Aliases

FScript2, a new way to build javascript plugins for FARR

<< < (3/7) > >>

mouser:
separate question is..

it sounds like youve created something extremely clever -- that lets existing plugins still THINK they are loading the fscript.dll but really are loading the new one through a proxy.

but here is my question about a possibly simpler solution:

since dll's are actually made to be shared if the same dll is in the search path, might a simple solution be for me to just have the core FARR load the fscript.dll from it's own program file directory (included with future farr builds) and add that directory to the dll search path?

does that solve the main problem of having ONE centralized fscript.dll or fscript2.dll that will be updated when needed, and preferably included with FARR install?

ecaradec:
Yes creating DLL by hand is possible and will work. Actually you only need write access when you add a plugin, remove a plugin or if fscript2 changed and it need to write a new version of the proxy. If you're not adding, removing or updating plugin you should be fine.

However I'd rather keep the proxy with the master DLL otherwise we could end up with various versions. There is very few code in them, but not none at all and it would be problematic if you needed to add new FARR API as I'd need to implement them in order to forward them and then all proxy would need to be modified. It is also important that they are located in a subfolder of fscript2 as they must be loaded AFTER fscript2 to be able to initialize correctly.

One way to solve it would be that FARR support some kind of proxy for DLL like a file that would point to the DLL to load instead or even better an API for FScript2 to allow it to load plugins. The alias wouldn't solve the write issue, but the API would. I wanted a version that works for every versions of FARR first so I went this path first.

We could wait a little to see if I can fix them that way and see the issues before moving to something else.

I'm already half crazy anyway ;)

ecaradec:
separate question is..

it sounds like youve created something extremely clever -- that lets existing plugins still THINK they are loading the fscript.dll but really are loading the new one through a proxy.

but here is my question about a possibly simpler solution:

since dll's are actually made to be shared if the same dll is in the search path, might a simple solution be for me to just have the core FARR load the fscript.dll from it's own program file directory (included with future farr builds) and add that directory to the dll search path?

does that solve the main problem of having ONE centralized fscript.dll or fscript2.dll that will be updated when needed, and preferably included with FARR install?
-mouser (January 08, 2011, 11:40 AM)
--- End quote ---

That's sound nice but I didn't exactly get you. Can you rephrase it ?

mouser:
Well what i was saying was simply this:

Let's first start at the begining:

* Fscript (and FSubScript) is one of the most brilliant things ever invented.
But it has one problem:

* As currently used, each plugin loads its own different copy of fscript.dll
* This causes problems because when fscript.dll gets updated, some plugins have older fscript.dll versions and they may have bugs.
The basic idea of the solution:

* Have all fscript-based plugins share the same dll.
And the specifics:

* Can't we just put a single fscript.dll in the FARR main directory and include it with all farr releases, and have farr tell windows that when a farr plugin loads, to use that version of fscript.dll for the plugin?  Wouldn't that be simpler? Or is there a problem with that that i'm not understanding.

cranioscopical:
I've been trying to drop plug-in items from FARR one at a time.
I had fscript2 working with just 1 plug-in (TimeZone - thanks Perry) but then FARR threw an error as soon as I tried to look at the plug-ins list.

Navigation

[0] Message Index

[#] Next page

[*] Previous page