It is not only Bob Keeney who finds his huge work to become obsolete: Any old example, sample project, old forum post, Google search result is now obsolete. BKeeney Softwares 65+ hours of Xojo training video that covers a good chunk of the Xojo framework is now practically worthless. I will be shutting the doors of the training site because its not worth my time (at this point) to redo over 200 videos.
Anyone ho tries to maintain and extend one or more business applications over the next ten or more years, will have to move to API 2.0. deprecated, but will still continue to work for a long time…. Well, Apple is proving this wrong, with shipping Catalina.
This release 2019r2 is just such a massive destruction of existing work, thousands of pages of code need to be touched, altered or completely re-written.
And as my apps are heavily database oriented, the recent changes give me a bad feeling: dropping record sets and trying to force us into the use of prepared statements could cause many issues, as the many database engines out there have implemented this in different, and not always flawless ways.
Anyway, to much unpaid work for me right now. Anyone who was creating video tutorials or books etc must feel like an idiot right now.
I wait now and will see if within the next 2 or 3 years Xojo will actually deliver: desktop, mobile and web. Right now I will not update, neither to Catalina nor to Xojo 2019r2 and I think I wont go to any conference either. Just a waste of time and money.
And yet Microsoft support Win32 after multiple attempts to replace it.
I spent > 250 hours working with the beta’s of this release and yes there’s a lot of code to touch. All of the work arounds that I had in place are now defunct. String.BeginsWith, String.EndsWith an entire class that mapped Xojo types to Database.BindTypes all replaced with Xojo Framework.
I can either use prepared statements (without having to specify bind types) or use inline sql injection. This hasn’t changed, just the bind types are now mapped.
Aside from having to remove my workarounds from my library I’ve had very little issues with 2.0 other than the huge number of deprecated items list - and Xojo could have done better with that.
I do feel for those of you that have produced training movies that now refer to deprecated events/methods and I would have hoped that there was a consultation between Xojo & yourselves though.
As many, many of us “I’ve been there, I’ve seen that”
Just my two cents:
From time to time things need to evolve in a way that results in these kind of massive changes and, yes, that implies a lot of work in all previous stuff that was working. (Motorola > PowerPC > Intel; Mac OS > first OS X releases )
One of the major recent changes in this sense that I have in the to the top of my head was the movement from Objective-C to Swift (think about all available third parties code, libraries, frameworks, books et al that come obsolete in a sudden)
Obviously, even today is possible to use both languages at the same time. (Change from Java to Kotlin in the Android world is more gradual, but it is also there.)
I think that the transition from API 1.0 > API 2.0 is kind of the same thing: we can still use everything was there, and move to the new API to the pace we want to do (even preparing new books, courses, etc.)
I mean, change is always there; most of the time for better things to come.
I think that is not about “destruction” of the existing work (because it is still useful for pre 2019r2 releases), but more in the direction of “evolution” to the future.
I can understand the frustration when having to rework or rewrite applications. Bob Keeney has indeed over 65 hours of training videos and they were excellent in their days. However, most of them were never updated. So Bob earned a lot of passive income from them.
But it is as with every online course, when the author doesn’t put efforts and time in it, they fade away, become obsolete and finally lose their value. That is what happened with Bob his video library.
Bob can shut down his video tutorial section or choose to update and maintain it. With the first option, he lose his passive income, with the second one he has a lot of work but also creates a new library which will give him again passive income over the years to come and I am sure, very good public relations for his other products. The choice is his to make.
Change can be painful but is necessary. Back in the mid-eighties, I wrote an application for an Australian farmer in BBC-Basic and assembler for the BBC-B computer. Mid-nineties I rewrote it from scratch in Visual FoxPro 3.1 for Windows. Between 2004 and 2005 I rewrote it again in RealBasic. It is still in use today by the next generation of the farmer who asked me to start this project. When I started I did it for free because in those days it was a challenge (no internet, correspondence went over mail) Also those rewrites or adding new features were free. The next rewrite (Python because it is open source and I want to give those people the ability to continue maintaining it when I am gone) is just looking around the corner probably next year, will also be free. Because I documented the whole application in the finest detail, it will be a little bit easier. However, I will spend again a massive amount of my free time in those rewrites.
A true developer pursues the goals and destinations he/she set for themselves no matter how bumpy or difficult the road will be, he/she will continue until he reached that goal. Staying behind with what you know or moving forward to an unknown future, the choice is all yours!
With a few exceptions, you dont have to make changes to your code. Heck, we added a way to select a block of code and automagically wrap it in #if XojoVersion so you could easily navigate that too.
Remember that the Xojo IDE, is a huge Xojo project with tons of legacy code. Were not suddenly going back to rewrite all of that old code if its not broken. Our current position is:
0. Existing, working code stays as-is unless theres some sort of demonstrable performance benefit to using API 2.
0. Existing code with a bug will be fixed using API 1 code to avoid confusion. We dont want anyone in the future to have to switch between the two.
0. Brand new code will use API 2.
Youre not forced to use prepared statements. Just pass a regular query like you did before without parameters and itll still work like before.
We worked very hard through this process to make it so opening an existing project in 2019r2 would work with very little effort. (To be fair, it had to be this way because we require the previous release of Xojo to build the current one.) Folderitem is a tough one because just about every project uses the when it gets beyond the simple tool stage. The fact that Apple finally broke something that theyd deprecated years ago just happened to coincide with our API 2 release, so you get a new underlying API and exceptions instead of error codes all at once.
Just so you know, every Xojo engineer has the same 20+ year muscle-memory issue that everyone is talking about and we still think API 2 is a good idea.
[quote=458010:@Greg O’Lone]Id like to get a few things straight.
With a few exceptions, you dont have to make changes to your code. Heck, we added a way to select a block of code and automagically wrap it in #if XojoVersion so you could easily navigate that too.
[/quote]
What the heck good does that do when, if you edit and save (NOT using save as) any code in 2019R2 you can not go back to an earlier IDE…
if that is true what good does XojoVersion do then?
But you never need to go back with the IDE… and if you find a bug in the new version of the IDE/framework you are working on, you can fix it… If we find a bug we can’t do that and may need to fall back to get things done.
[quote]
Just so you know, every Xojo engineer has the same 20+ year muscle-memory issue that everyone is talking about and we still think API 2 is a good idea.[/quote]
Some of it is and some not…
By changing the events you took away the realistic possibility of going back if we needed to and for more than few that is a big deal.
And then there is trying to force the Xojo framework ideas down out throats… there was no need to deprecate the global methods and only have extension methods… It just makes coding in some situations more awkward.
You kept string … sort of… but deprecated the B methods… There are times that treating a string as a bucket of bytes is useful… and the overheard of creating a memoryblock and copying the data requires coding and is a performance penalty which can be a problem in some cases.
Well you will find out how widespread issues with these changes are in the user base in the next year or two by renewal rate.
Option - do NOT show API2.0 deprecations when doing an Analyze Project
Option - disable Autocomplete of API2.0 items
At least this way a developer could continue in the API1.0 world without having to wade thru tons of messages they KNOW they don’t care about in the moment
Option - do NOT show API2.0 deprecations when doing an Analyze Project
Option - disable Autocomplete of API2.0 items
At least this way a developer could continue in the API1.0 world without having to wade thru tons of messages they KNOW they don’t care about in the moment[/quote]
Not having the API 1.0 documentation handy is an issue if one wants to keep working with it… The only solution I can see would be to ALSO have the 2019R1.1 IDE open to access it’s local help.
I think biggest problem here is that things are not well thought out to the end, and also not done in a way so that much needed language improvements and benefits actually come to the users.
The big picture of course is that we have training material, we have 3rd party codes we have Plugins which use API’s internally, and some of the new things can’t even be loaded from a plugin currently for example.
Many of the new things are all good and fine…but changes like this should also introduce benefits to the user, and none of those changes is really catching up on where Xojo has drifted behind everything else on language features.
The change of Events to me is just nonsense that one was “just because change” and was no need for it. (I know others might have different view on that)
The event craziness really should get reverted. And there should be setting to disable warnings from new vs old AP without you loosing all the other warnings that you want to see.
Importing old projects should have updated or offered to update all the simple syntax changes DrawRect to DrawRectangle… for example. Leaving only those that actually need thought into changing.
Edit: At the End of the day though I support changes and evolution…I just wish good thought would be put in it and that we would get some of the much needed improvements that Xojo and its users deserve.
I perfectly understand the frustration of Oliver, what I do not understand is why API 1 is deprecated from day 1?
With the amount of information it becomes difficult to quickly see which code is truly deprecated and which one can wait for a fix. I have nothing against API 2, the language evolves with new features and it’s a good thing and the Xojo team did a good and a lot of work on it.
My problem is more related to compatibility with R2 and before R2, I work on client projects that still use the 2015, 2016 and even 2011(PPC) versions.
Take the following example:
I start a new project with R2 so it use automatically API 2, I create a new control based on a canvas with opening etc … Once the application is complete, I want to use my new control in an old project (even created with 2019R1.1) => it does not work, I have to re-create it!
I also share Dave’s opinion and for me a simple possibility would be to have an option ‘Supports API 2’ (same as ‘Supports Dark Mode’). If the option is ON the result is identical to the current result of R2, if it is OFF, all new events would be created according to API 1 and without a big list of deprecated items. In this case the user could choose whether he needs compatibility or not, and decide when he wants to move a project to API 2…
Now is a really risky and crucial moment for Xojo. How many of us will give up on Xojo?
The new framework turned out to be a shot in the oven and developing for iOS never really took off either - and who is going to invest in this direction now, when we can expect a fundamental change to iOS development somewhen in the future?
Will there be anything reliable in the near future or can we throw away our work again in 5 years from now?
I think ultimately we can work around everything in the new API except for events. If someone takes a class I made that uses the Open event and then implements that Opening event my old Open event no longer fires. It fails silently and that is my biggest beef.
I think what I’d really like is a compiler Error that says “Opening event has caused an implemented Open event to fail.” That’s the only way API 2.0 events can co-exist with existing API 1.0 events. Otherwise any 3rd party code has the potential of failing silently.
You can’t wrap #if around events. We have no ability to control what another developer implements. Another possibility is a compiler flag that means, “Must Use API 1.0 events”.