I have a strange issue with label text in 2015r2 that I don’t have in 2015r1 from the same source code.
2015r1:
2015r2:
This is the code for the label text in the label.open event:
Me.Text = kVersion + " " + Str(App.LongVersion)Any idea what’s going on here?
Whats in the Shared build setting long version setting ?
The long version in the Shared build settings is 4.2.3. The copyright text in place of the version number in the 2015r2 build appears to be coming from the App Wrapper Mini build script in the OS X build settings.
If it replaces the text in the plist then thats what you’ll see
In 2015r1 the data was in the plist under CFBundleGetInfoString
In 2015r2, since that key has been deprecated by apple, this is now under NSHumanReadableCopyright
It’s always been read from the plist BUT, if App Wrapper added the NSHumanReadableCopyright then you might have both.
But, as I said, that old key is deprecated so we do not use it incorrectly any longer.
I believe this accounts for what you’re seeing
App Wrapper Mini does add an NSHumanReadableCopyright key but I don’t see how that would get read as the app version unless you’re using a simple list count based on where you expect things to be rather than parsing the keys for the relevant data. If I check the info.plist in Xcode they are the same for the builds from both IDE versions.
The wrong thing in Xojo 2015r2 is that for Mac, it uses the LongVersion string as the string for NSHumanReadableCopyright. 
The replacement is correct - NSHumanReadableCopyright replaced CFBundleGetInfoString
CFBundleGetInfoString was previously the Long Version String
From Apple’s Info Plist Guide
NSHumanReadableCopyright
NSHumanReadableCopyright (String - OS X). This key contains a string with the copyright notice for the bundle; for example, © 2008, My Company. You can load this string and display it in an About dialog box. This key can be localized by including it in your InfoPlist.strings files. This key replaces the obsolete CFBundleGetInfoString key.
But the IDE says LongVersion not CopyrightString.
And in the Windows target, LongVersion is exactly used for Long Version.
I know Apple can see things in that way, and me too if I have to build only for Mac. Simply use the LongVersion to put the copyright.
But since Xojo is cross platform, and I have to build cross-platform, I can’t have a field named “LongVersion” used in the right way on Windows and wrongly on Mac.
How do I manage this then?
From these settings
I have these on built apps:
Perhaps a new field is needed in the OS X specific settings, like many exists for the Windows target.
Long Version has , on Mac OS builds, always represented the “Copyright info” - at least the “Get Info” string which is why it was in CFBundleGetInfoString
However, calling it Long Version in the IDE when it’s supposed to be the copyright string is rather nonsensical, especially when App.LongVersion has always provided the long version until this release.
This could be a convention, you know, but since you provide quotations from the Apple bible, you should also agree that a thing is a thing, not what is said of that thing.
So, again, I read on the IDE LongVersion, not Copyright info.
And btw, even writing this on manual will not change the facts.
In Xojo.LongVersion we want the VERSION, not the COPYRIGHT. Just as on Windows.
Isn’t Xojo supposed to be cross-platform?
And supposed to shield us from these internal inconsistencies and maintain backwards compatibility?
After all we program in Xojo, not in xCode.
Hi,
I found this on page 170 in the “UserGuide-Fundamentsla.pdf”, Xojo 2015r1
It seems to be longer like this.
"Short Version*:
A short text description for your application. Usually this contains just the version number (such as 1.2.3.4) and is displayed by some operating systems in Get Info or Property windows for the application.
Long Version*:
A longer text description for your application. Usually this contains the application name, copyright, version and other information. This is displayed by some operating systems in Get Info or Property windows for the application."
The term Long Version could be misinterpreted by many programmers as a long Bundle Version. Perhaps it would be better to rename Long Version to someting else.
[quote=180549:@Torben Vikow]
The term Long Version could be misinterpreted by many programmers as a long Bundle Version. Perhaps it would be better to rename Long Version to someting else.[/quote]
And then it will misbehave on Windows!
I already said this: writing it on a manuals doesn’t make it magically true.
Long Version and CopyrightInfo are two different things and here Xojo is trying to fit one information in these two slots.
I did go back and read the description of LongVersion in the language reference and it does include more than just the version number. Using App.ShortVersion rather than App.LongVersion to get the version number solves the problem I was having with the version number display in my app’s About box.
[quote=180550:@Massimo Valle]And then it will misbehave on Windows!
I already said this: writing it on a manuals doesn’t make it magically true.
[/quote]
Its been this way for a VERY long time & documented this way for that time. Heres the text from the 2007r4 Users Guide
The File Version field on the Version panel concatenates the MajorVersion, MinorVersion, BugVersion, and NonReleaseVersion properties. The Description field contains the value of the PackageInfo field and the Copyright field contains the contents of the LongVersion property.
“Long Version” has been the item that showed in the get info window as what is now known as copyright for a VERY long time.
Its that item in 2012, 2011, 2010, 2009, 2008, and every version I launched as far back as I checked.
The only thing that changed was the PLIST key that this data is being written out under.
Now, because we use the correct one, App Wrapper or any other tool changing it makes your long version change as well.
The only way we could deal with this would be to write it twice.
Once to the plist as this specific key so that if you don’t use a tool like App Wrapper the get info window is correct.
And once to some other internal key that a tool like App Wrapper and the Finder would NOT use.
And then we read this key back in from the plist (as it can be localized so we HAVE to read it from any localized string sets that might exist)
Finder seems to think differently:
But again we need a cross platform solution for Xojo.
So please tell me how I can fill the LongVersion in both Windows and OS X without seeing it as a CopyrightInfo on OS X.
I’m not surprised the Finder doesn’t show the older key - its deprecated so it probably ignores it entirely.
The recommended plist key changed. Apple deprecated the one we had been using.
So we updated the key its written as.
Now it shows the copyright info and has been documented as doing so for a very long time.
This isn’t new in any way shape or form.
What was new was that it WASN’T being written in a way the copyright info in the Finder would show.
[quote=180629:@Massimo Valle]Finder seems to think differently:
So please tell me how I can fill the LongVersion in both Windows and OS X without seeing it as a CopyrightInfo on OS X.[/quote]
[/quote]
Well since we have long documented that this IS where copyright info comes from it’d be a change in behavior
That would be a feature request
You COULD use a dynamic constant to have different values on Windows & OS X though
This is wrong.
If you check the pictures I posted, you can see Finder doesn’t ignore the CFBundleGetInfoString if present.
[quote=180723:@Norman Palardy]
Well since we have long documented that this IS where copyright info comes from it’d be a change in behavior
That would be a feature request[/quote]
HA! Norman “Feature Request” strikes again. 
Norman, the only thing more annoying of Xojo misbehaving, is your behavior in this kind of situations.
It’s utterly unbelievable that a customer spend time in test, check and isolate where Xojo misbehave, discuss in the forum to get help, file Feedback requests, just to see you closing immediately the Feedback case (by Design).
And then, everything not working as it should, for you, is a feature request!?! That’s ridiculous.
I’d define this as FD. Flawed by Design!
This is not only disrespectful for the engagement and fondness of (paying) Xojo customers, but it’s counterproductive for Xojo itself.
Even supposing this would be a feature request (which is not IMHO) why did you close my Feedback case?
The minimum reasonable expected behavior would have been you to change it to a feature request.
But no, you like doing the Feedback cop and close as many cases you can.
However the fact remains, despite what it’s written in the manual.
Even if this is written from long time, this doesn’t make it magically correct.
In the end, I lost time, money, I’m baffled and still the only solution will be to fix tenth of Xojo projects because Xojo do not want to fix a bug.
Thanks Norman, thanks Xojo.
The feature request would be to provide separate fields for Copyright, short version long version & perhaps other fields
That’s completely different than what your report was about
And different than what we’ve done & documented for the last 10 years with this particular item
I have no problem with such a request
I’ve altered yours