Currently we are using RB 2008 r4.2. I believe it’s time to upgrade but management has a different opinion. They won’t spend the money for the licensing unless I can provide clear reasons why we need to upgrade i.e., “does the new version have bug fixes and/or new features that we require or would like to have?”.
Is there an online change log I can use to build a list of reasons why we need the newer version?
All are not there, but a lot are !
Alberto: you were some seconds faster than mme on that one !
Emile, thank you for pointing that out (all are not there). After following the Older Release and Legacy Release, I see notes from 2010 R 2.
Ron, I think you should read the release notes to see if there is some feature that you want or need, then download Xojo and try it. I’m new to Xojo but I guess a lot has changed since RB 2008 r4.2
Wow, that was fast. I step away from my desk for a couple minutes and there you are.
Thanks for the link. I’ll look that over in a little bit.
[quote=374507:@Ron Bergin]Currently we are using RB 2008 r4.2. I believe it’s time to upgrade but management has a different opinion. They won’t spend the money for the licensing unless I can provide clear reasons why we need to upgrade i.e., “does the new version have bug fixes and/or new features that we require or would like to have?”.
Is there an online change log I can use to build a list of reasons why we need the newer version?[/quote]
Depends on what platforms you are targeting. For desktop there lots of little bug fixes and some new things, but not much major in terms of functionality (lots of time spent on the new Xojo IDE and the new framework), unless you need 64 bit or Windows flicker matters to you… Some think the Xojo IDE is a step backwards from REALStudio.
Regardless, since they won’t let you stay current, if you get permission to renew, IMO you should wait until after 2018R1 comes out. Hopefully that would get you to 2019R1 on the renewal.
[quote=374509:@Alberto De Poo]Maybe this will help:
http://developer.xojo.com/release-notes[/quote]
Thanks Alberto. It’s going to take me a little time to go through those release notes but it looks like what I need.
Compile for 64-bit. (End of discussion)
Karen, good suggestions. By the time I build and submit the case for the upgrade and have it approved, I’m sure 2018R1 will be out.
BTW,our main target is Windows 32-bit, but we are slowly moving to 64-bit systems.
After some minutes, I recall the most important “upgrade” feature.
Not knowing your running platform, it is a bit hard to enlarge the 64bit feature. For macOS, no non 64 bits application can run sometimes later this year.
What real plus to say about 64 bits on Linux (no more distro in 32 bits ? No, Linux users are conservatives) and for WIndows ? (WIndows 7 SPI is the minimum version to run) ?
Internet security ?
Today I got my first ever ‘hey do you guys do your Windows software in 64bit?’ question.
I suppose more memory space would be nice but right now there seems little call for a 64 bit Windows build.
One thing I forgot to mention as a major new feature is retina (Hi-DPI) support. At this time that matters more on a Mac than a PC IMO.
64-Bit support is required for the next version of the macOS, where Apple say that 32-Bit apps will run with compromises (but we don’t know what they are).
The biggest compromise right now?
The blatant lie of:
‘This app is 32bit and will slow your Mac down’
…Making the customers nag the developers into doing a 64bit build
My 32bit builds have run fine for years and still do, and can in no way slow down someone’s Mac
I’ve tried to switch to 64 bit at a number of times over the last year - but I’ve had to pull the 64bit version 5 times so far due to inexplicable 64 bit graphics issues. (32bit continues to work fine)
Eg last week I found that a routine which created a little preview image by setting pixels using rgbsurface.pixel() was broken on 64bit builds because it was setting 2 pixels at a time instead of one.
using graphics.pixel() and changing no other code ‘corrected’ that, but c’mon…!
It feels more like ‘you must switch to 64bit but when you do, it will be compromised’
[quote=374556:@Jeff Tullin]Eg last week I found that a routine which created a little preview image by setting pixels using rgbsurface.pixel() was broken on 64bit builds because it was setting 2 pixels at a time instead of one.
using graphics.pixel() and changing no other code ‘corrected’ that, but c’mon…!
It feels more like ‘you must switch to 64bit but when you do, it will be compromised’[/quote]
Though in all fairness that isnt Apples but Xojos issue.
I didn’t know it was a known bug in Xojo
That makes this become a worrying statement:
[quote]Graphics.pixel
This item has been DEPRECATED since version 2016r1 and should no longer be used.
Please use RGBSurface as a replacement.[/quote]
Feedback ASAP!
Didnt say that. But I would be surprised if it is an Apple bug.
Graphics.pixel isn’t marked as deprecated when doing an analysis on the project.