I often work with external libraries available for macOS and Windows.
While their features are xplatform, I have to address the correct library according to the current platform.
In theory, this could be doable with a dynamic constant set to the platform.
But what to do with different Win32/x86 libraries?
There is no optional CPU Bit selector available for constants.
While the IDE supports the platform buttons, and while this works nicely with usual methods, they are ignored for a constant. When I try to rename the duplicated and modified LibraryName1 to just LibraryName after having checked/unchecked the 64 bit/32 bit buttons on the constant, the IDE tells me that I cannot do so because a constant of that name already exists.
So I usually find myself duplicating all kinds of external and internal methods just because of different library names where either one optional selector in the constant editor (for 32/64 Bit) or the IDE respecting the platforms buttons would make life much easier.
Did I miss anything and this all is indeed much easier to accomplish?
Do feature requests exist that ask for such a feature?
As always: Thanks a lot!
@Ulrich Bogun You may want to consider using some dynamic call library like DynCall (dyncall.org) or, but less easy, LibFFI (preinstalled on macOS). With that, you can call any library dynamically.
It would take you time, but it could be worth it in your case.
In a constant you CAN add a value for each platform even if it is NOT a dynamic constant (ie/ localizable string)
At compile time the specific value for each platform will be sent to the compiler
[quote=471287:@Norman Palardy]In a constant you CAN add a value for each platform even if it is NOT a dynamic constant (ie/ localizable string)
At compile time the specific value for each platform will be sent to the compiler[/quote]
Yes, thats basically what I wrote.
What I miss is the opportunity to add separate values for separate platforms AND CPU bit widths.
@Stéphane Mons : Sounds interesting, thanks!
(Id prefer a built-in way though, but could be a workaround.)
yeah constants do NOT permit different bit widths (i’m assuming you means 32 vs 64 bit ?)
but in that case define 2 - one for 32 bit suitably named and one for 64 bit suitably named
the other way is to just wrap the declares in a suitable Xojo method and then inside each method deal with these differences in there and hide the fact there is any differences from the library user entirely
the trouble with something like libFFI is now you have another dependency somone has to install to use your code AND it still wont let you call a 64 bit DLL on a 32 bit system (and vice versa)
Well yes, thats what I do and what makes me duplicate all external method just because of different naming.
Which is work Id rather save. So its probably time for a feature request.
Yeah in this case I would not even use external methods
They just dont have the same flexibility