Xojo 2020r2 is available (for some)

More infos here:

The roadmap file have been modified according to the above new rlease:

wow, here I was thinking my licence would expire without any more updates, a week left and most unexpectedly an update!

I am lucky, another version of licensed xojo that’s no use to me.

Why?

If you don’t want it I’m happy to take it :hugs:

1 Like

if @doj is in the same boat as me there isnt anything that got fixed that I needed
dont care about mobile
dont care about ios
dont care about web2
so releases that focus on those dont tend to do much for me

1 Like

yup, ALL my code base is never going to be API2 based, too much work to update and no one would be inclined to pay to make it do exactly the same thing.

I also have no wish to learn a whole load of newly named things nor use new classes that have unknown bugs in just for the sake of it.

I am interested very much in Web, but not with Xojo, too expensive, too immature, too buggy.

1 Like

I’m interested in the “Worker” control. I assume if I install the new version, like in the past, I can create debug apps without buying?
Won’t hurt my 2019r1.1 install? That is to say, I can have both 2019r1.1 and 2020 on the same machine with no issues? (as long as I don’t accidentally open a 2019r1.1 app on 2020 and save it?)

Yes you can run both versions same as always
Just be careful with workers as they have this weird set up where what works in Debug MAY NOT work when you build
I reported it before they shipped but they made no changes to it so I expect they’ll get complaints eventually (The bug report is private although I have asked it be made public)

1 Like

I think that assumptions are a no with Xojo :sweat_smile: To “test” the feature you need a licence and actually build the app. In debug mode, the feature is emulated with threads. So, in debug, you have a single core as allways.

At some point I had 4 different versions due to incompatibilities and lack of time to update the code to be “latest” version compliant

It happens :frowning: and you could lost the code.

as long as you do not do a “SAVE AS”.

i use multiple version of xojo and open in xojo 2017, xojo 2019 amd xojo 2020r2 without much problem.

Are you sure of that?

I know that originally was how it was supposed to work, but I thought awhile back I tried doing a save in some version after 2019r1.1 and then was unable to open in 2019r1.1.

Since then I only used newer versions to compile or to test things.

I could not risk my current project becoming incompatible with API 1 only IDE’s as I need backward compatibility.

-karen

and since it is a thread you CAN refer to things outside the worker (say something in App) that will work in debug mode but will not Build

I have 14 versions available all the way back to 2017r3
other I have in VMs etc as they are even older

Well, that sucks. I need to see whether doing some stuff via a worker will speed up the process. If it uses Threads in debug mode, that’s not helpful… I can use Threads in 2019r1.1!

1 Like

You can always use Thomas Tempelman’s Multicore template which works in older versions

1 Like

Sad for you (and your avatar picture certainly reflect that feeling :wink:). What did you wanted to get fixed?

There are also workers and graphics brushes that aren’t part of your listing. While, for me, both are a welcome addition, I understand not everyone is interested in the brushes. But workers… while being limited (how to pass pictures back and forth, for instance?), I’m thinking most users making an “advanced” application can see the benefit of them.

With this release, I thought there were additions to make most users somewhat “happy” (I’m feeling there are more useful fixes and additions than when they focused mainly on web 2.0). I’m sad to see this release didn’t make the changes I expected.

mine goes back to 2014r2.1 for one client… the rest of windows clients , i keep it at 2017r3 and going move mac clients toward 2020r2 (currently on 2019r1.1)

Thank you, @MarkusWinter. Hadn’t seen that one before. It seems though, that this implementation requires the transfer of data between the running gui app and the console worker. My requirement is that the worker app add items to a stack or an array that can be read by the Gui app anytime, otherwise the passing of data back and forth would further slow the procedure.
I don’t know if the “new” worker class in 2020 also requires data to be sent back and forth, or whether the worker app can access data directly?

maybe a few of the 15+ compiler bugs I’ve filed that are marked reproducible ?
some of the xojo script bugs I’ve filed which are reproducible

Workers are just console apps and helpers made with a console app
Thats been possible for a long time so worker just makes that marginally simpler (but has this weird set up where what works in debug might not work in a build)
And, fwiw, I dont need them either (or brushes)

1 Like