> [...] and the bug disappeared (for now...)
We're also using VC6 for some purposes here ...
... but (still) without any problems on compiling and using Silverjuke plugins. However, we can imagine various reasons that this will fail
> But the new example is a very good idea [...]
> Might I suggest one tiny change for the example:
> rename the stringid used internally to the DLL to
> something other than the functionname?
You are right, using the function name here may be confusing. We're now using ID_FOO instead.
Best regards.
Your Silverjuke-Team
Statistics: Posted by Service-Team — 7. Mar 09, 12:27
]]>
I updated my MSVC-compiler to the newest version (latest patch for 6.0 that is - never saw the need to upgrade any further - created in 1998 and stil going strong
) which I forgot on my latest machine - and the bug disappeared (for now...). But the new example is a very good idea, the info how to combine it all to call a DLL from script was all present in the SDK and forum, but it was very hard to piece together when I started my first DLL.
Might I suggest one tiny change for the example: rename the stringid used internally to the DLL to something other than the functionname? There is no technical link between them, and the way the exportedFunction script-function-pointer turns up as a string in callExported is already confusing enough without suggesting any relation to the string used for the callPlugin() to SJ_PLUGIN_CALL-param1 communication.
Thanks,
SilverEagle
Statistics: Posted by SilverEagle — 7. Mar 09, 00:30
]]>
we've tested the described situation - and added a new example to , see foo_exported.dll.
However, our example works without problems - even if we force an error. Maybe you can compare your code with ours and find some problems this way?
BTW: Currently, *.dll files always get loaded before *.sj files, so the exported function should be available.
Best regards,
Your Silverjuke-Team
Statistics: Posted by Service-Team — 6. Mar 09, 12:21
]]>
]]>