I explain how in
https://www.great-white-software.com/blog/2019/07/24/making-platform-specific-error-codes-generic/
I explain how in
https://www.great-white-software.com/blog/2019/07/24/making-platform-specific-error-codes-generic/
This case is with MacOS having value 1 on Intel and value 2 on Apple Silicon.
Not sure whether Xojo can do that.
Thanks Norman.
So rule of the thumb is to create two enums. Then a thrid set of the values as constants, which can be used to tie together the two sets of enums, very clever. This is why we need you still.
However I donāt see how to specify one for Intel macOS and one for ARM macOS (which is the problem).
Why? What is the difference to TargetCarbon and TargetCocoa, or TargetMac or TargetLinux, or TargetLittleEndian and TargetBigEndian?
And if you mean āwhether the CURRENT version of Xojo can do it?ā then as usual terminal is your friend: according to Google the command uname -m
returns the exact architecture of the machine (x86_64
or arm64
)
@MonkeybreadSoftware is referring to specifying different values in a enum for different CPU architectures (which is the problem I raised yesterday).
@npalardy suggestion is very clever, but unless Iām mistaken this is for different platforms and not CPU architectures.
āAre you merging iOS and MacOS?ā At the companyās WWDC, Senior VP Craig Federighi wanted to tackle it head-on, saying, āIād like to take a moment to briefly address this question. NO. Of course not.ā
NSText.h under the macOS SDK.
#if TARGET_ABI_USES_IOS_VALUES
NSTextAlignmentCenter = 1, // Visually centered
NSTextAlignmentRight = 2, // Visually right aligned
#else /* !TARGET_ABI_USES_IOS_VALUES */
NSTextAlignmentRight = 1, // Visually right aligned
NSTextAlignmentCenter = 2, // Visually centered
#endif
I smell burning pants from over here.
Why? Sure, the code is somewhat redundant, but why would they use different values for NSTextAlignmentCenter on different platforms??? Seems to me more like a boilderplate code that reminds them āit could be or become different on the different platforms, so for future proofing always add the option to change itā
My guess is when they ported AppKit to iOS, someone changed the order of the values in the enum. Its only a problem because theyāre merging the macOS and iOS and iOS compatibility takes precedence over macOS compatibility.
NSTextAlignmentCenter produces centered text on a x86 compiled application (even in Rosetta on a M1 Mac), and right aligned text on a arm executable (on a M1 Mac).
Sorry, brain-fart on my side. I could have sworn the lines were just switched, eg the enums still had the same values.
No worries.
They merged a lot of the underlaying frameworks.
Well, as there is no old macOS app using the old constants, they could easily change that.
The iOS Binaries to run on Apple Silicon Macs were already compiled with iOS constants.
The better question is why they had been different all the time anyway.
Ok what am I missing here. for both Enum and Constantsā¦ why does it matter what the rawValue is?
Isnāt that the whole point?. Unless your code is using the rawValue (in which case it should reference it from the Enum anyways)
if x = 3 /// wrong
if x=enumABC.key.rawvalue /// works regardless
I write Swift for iOS/macOS and to be honest never bothered to see if they had different values. You should not have to care