Page 1 of 1
One extension with multiple native library implementations
Posted: Mon Aug 06, 2018 7:59 pm
by bmont
Is it possible to have one extension with multiple functions that are implmented using native libararies from multiple platfroms?
Re: One extension with multiple native library implementations
Posted: Mon Aug 06, 2018 8:19 pm
by trevordevore
While I haven't tested it, I would think so. LiveCode doesn't try to resolve external code libraries until you actually call the function. You could probably do something like this:
Code: Select all
# Define private foreign handlers that access native libraries on Windows OS
...
# Define private foreign handlers that access native libraries on macOS
...
public handler doSomething returns String
if the operating system is "mac" then
# Call Mac native library handler defined above
else if the operating system is "windows" then
# Call Windows native library handler defined above
else if ...
end if
end handler
Re: One extension with multiple native library implementations
Posted: Mon Aug 06, 2018 10:28 pm
by bwmilby
There is an example on GitHub where they have one widget include native controls for several platforms. That one is done with sub-modules, but I would agree that it should be possible.
Re: One extension with multiple native library implementations
Posted: Mon Aug 13, 2018 9:33 am
by livecodeali
Yes, the cross platform button example is how we would recommend structuring such an extension:
https://github.com/livecode/livecode/pull/6266
However it does potentially over-complicate things it if the extension is very simple, and you can do as Trevor suggests (in fact the first LiveCode widget to do such a thing was the map widget - it was implemented exactly this way with all the code in one module).
Re: One extension with multiple native library implementations
Posted: Mon Aug 13, 2018 10:50 am
by LCMark
Just to expand on what Ali and Trevor mentioned about this...
The LCB runtime does not bind to a foreign handler until it is used - so you can have all bindings for all platforms in one module.
Even if we change this at some point (for efficiency reasons) it would still work the same way from the point of view of running code.
i.e. Only things that do bind on the current platform will bind. Any error from binding ahead of time (e.g. from trying to bind to an obj-c handler on Windows) will just throw the appropriate error on first use.