SDK and AddExtender() Feature Request

[JTaylor]

I realize this addresses a problem I have created but I think would potentially help others as well, especially those who use my Extender.   It would be nice if the Extender SDK would allow one to assign a Group name to each function in m_ExtTable[] and then when one Runs AddExtender(), it would contain a parameter for a Group name and it would only load those Functions and Constants.  Perhaps an ALL group which gets loaded no matter which Group parameter is used.  Mainly thinking of Constants here but could see some functions falling into such a group.

As you may have noticed, I have bundled all my Extenders into one.  This has upsides and downsides, as with most decisions in life, with one of the downsides being the number of functions hit the limit when included with other Extenders.   

Maybe with this feature you would consider bundling all of your Extenders into one, since one of the upsides is not having to keep up with all the various extender files.   Maybe even bundle it into the main install so one doesn't have to go and download those separately.   Better quit as I am getting carried away as I keep thinking of possibilities  :-)

As always, thanks.

Jim

[JTaylor]

I would add this would be helpful in one or two of your Extenders such Winsock and WinInet.

Jim

[ChuckC]

Why not just have the upper limit increased for the maximum number of extender-based functions?

[JTaylor]

That is an option as well.   Not sure how that might affect performance.   I assume they set a limit for a reason?   I think they might have boosted it to where it is now because of me but can't remember for certain.   I assume the fewer loaded functions the better but, again, not sure.    If the numbers don't matter, raising the limit works for me and is, obviously, the easier option.


Jim

[ChuckC]

I think it's just an upper bound on a statically sized array.  To me, that sounds like something that should be heap allocated with a dynamic size provided via an override obtained from "the outside" [larger than the built in default], with a fallback to a built in default value should there be no override provided.  I leave it up to Tony to specify how the override value is provided.  Maybe it could be some directive in the very beginning of the script code before any other "functional" statements are executed, or perhaps it could be provided via an INI file or some other file co-located with the compiled script's EXE file or the interpreted script's WBT file.  Think along the lines of how Microsoft has XML files co-located with binaries to provide their "manifest" information.