I’m here for you. 
Kem is there for you.
[quote=458840:@Beatrix Willius]
@Dave S: and if you don’t update you get whining customers.[/quote]
Therein lies the problem
The Xojo third party market is tiny and so developers need to support new and old versions
API 2 makes that VERY difficult
Have any third parties said they are updating their controls/libraries/add-ons to be API 2.0 only ?
The latest Einhuger Date Control has two flavours.
What you can do in a plugin vs what you can do in Xojo code is one issue
In pure Xojo code its literally not possible to have a single control support both API 2 and API 1 at the same time
You get compile errors
I probably should have said
Have any third parties vending Xojo code add ons (m_string, graffitisuite, etc) said they are updating their controls/libraries/add-ons to be API 2.0 only ?
To the contrary we have to talk about competitors (or frriends). If only,because some decisions comes from what they do !
We only do not have to make advertising for competitors. Telling the whole market place have VAR (instead of DIM) is talking about what the market do/is (competitors !).
[quote=458852:@Norman Palardy]What you can do in a plugin vs what you can do in Xojo code is one issue
In pure Xojo code its literally not possible to have a single control support both API 2 and API 1 at the same time
You get compile errors
I probably should have said
Have any third parties vending Xojo code add ons (m_string, graffitisuite, etc) said they are updating their controls/libraries/add-ons to be API 2.0 only ?[/quote]
Well I will have API 2 only version of ExcelReader on the weekend (That one is Xojo code module and no plugin)
Obviously I have to provide API 1 version also.
(And internally of course when its adding to the Column arrays then it does AddRow as strange as that sounds)
[quote=458864:@Björn Eiríksson]Well I will have API 2 only version of ExcelReader on the weekend (That one is Xojo code module and no plugin)
Obviously I have to provide API 1 version also.
[/quote]
Having to have two distinct versions for API 1 vs API 2 is part of the pain vendors like yourself have to wrestle with
Many have said “our products will remain API 1.0 only for now”
Many of us have already started converting their projects to API 2.0 and invested countless hours. There is no going back.
Now that the situation is as it is, I argue that we stop complaining about it and that we are trying to help Xojo Inc. finding ways to make it easier for us to transition to AND to maintain the old language.
For those who have significant code bases where they cannot use R2 your advice is to do what ?
Stay on API 1.0 with current PlugIns until it’s easier to update to API 2.0?
AND i’d still like the Xojo 2019 R1 LTS idea…
[quote=458869:@Sascha S]Stay on API 1.0 with current PlugIns until it’s easier to update to API 2.0?
[/quote]
And this IS the problem I was meaning
IF I write a control in Xojo and try to sell it to people using 2019r2 and 2019r1 I have to pick ONE API to support
I cannot support both with one control
OR I have to have 2 versions - one for 2019r1.1 and older and one for 2019r2
Thats the problem and why creators like Kem and several others who write controls in Xojo, not plugins, have decided NOT to update them to API 2.0
This is in my opinion just a temporary issue. If you NEED to use a Plugin and it’s only available for API 1.0, you could just ignore the deprecation warnings surrounding this plugin.
I am currently updating a Project with over 11k deprecation warnings. At some places i can’t update to DateTime because Einhugurs DateControl is not (yet?) supporting DateTime. But i don’t complain, i update everything i can and hope in the future there will be a Einhugur DateControl that supports DateTime or i replace it.
I surrender
You’ve missed the point
[quote=458891:@Norman Palardy]I surrender
You’ve missed the point[/quote]
Sorry…
[quote=458866:@Sascha S]Many of us have already started converting their projects to API 2.0 and invested countless hours. There is no going back.
[/quote]
And many of us have decided to wait and see if it is going to be worth going forward first.
It means “No Catalina for you”.
Depends on what you do within your App.
Trust me, i also have my issues with the move to API 2.0. But i do not want to waste much more time complaining…
We did the same. But i offered to update our Code to API 2.0 in my spare time, to make us able to use 2019 R2+ Versions.
I have an API 1.0 large code and a pile of API 1.0 updates to do. I can’t stop for a “I don’t know how much time” to convert using bad transitional tools to something that, at end, could just crash with multiple bugs on the first run, while postponing that 1.0 fixes and features, that I must to do ASAP.
More people are in the same boat. I don’t have a simple code needing a conversion, a have a dynamic code, evolving everyday, needing a conversion. I need to stop the continuous update, stop the delivery, and do the job at once. Right now I prefer proper 1.0 handling on 2019r2+ and maturing the transition tooling for a fast conversion. Having compiler message filters could help a bit. Xojo eating their own dog food to understand it could too.