Well done… 
No need to listen to anymore cause that he should listen to before even thinking of the changes starting with 2020r1. No reliability is not usable for development. Praying that it is no problem is not solving that.
IMO, it is less about a potential API 3 than about the fact that web targets and arguably mobile targets, are Not Ready for Prime Time. I think API 2 has been enough of a debacle that it’s unlikely to be repeated, and to be fair, API 1 is still supported at least on desktop. But like this guy, my main interest in Xojo was as a solid abstraction for multiple targets and I’m not sure it’s all that solid even for just multiple desktop targets judging from bugs people are reporting.
Yes they unnecessarily shot themselves in the foot and lost a lot of good will from long term users who were willing to overlook a lot of issues because they liked the product… but API 2 broke the camel’s back…
BTW the person who started that thread asked me if I had updated my Mergable Cell Listbox to API 2. He was unaware I had open sourced the API 1 version and had said I would not.
Because I had not, he asked me if I knew of an API 2 Listbox/grid control control that could merge cells across both rows and columns as mine can.
I am not aware of any that can do that. Does anybody here know of one?
I took a quick look at the GraffitSuite grid docs, but did not see anything about merging (though I could have missed it) , and I don’t think Einhugur has a listbox with that capability either.
-Karen
Agreed
I do not either
unlikely maybe in name, remember that before api2, they had the “new framework”, same useless waste of time for them and for the users when it was deprecated.
supported? They already stated many times that api 1 will not have bug fixes. Leaving it there is not really supporting it.
I wouldn’t exclude such things to happen again. There is no observable change to the ‘we couldn’t care less about your concerns’ and ‘we know it better’ attitude.
And the few long term developers who complain and eventually leave the platform are entirely insignificant when compared to the total base of hundreds of thousands of (active) developers.
I assume you omitted the sarcasm tag? There’s no evidence they have that many active developers.
the new framework was killed based on user complaints about “walls of code”
not for technical reasons
given what I know about how things work that will be hard to fix bugs only in API2
At least for now most old and new items use the same underlying code
Point a debugger at an API 1 app and an API 2 app and you’ll see this
I had a bug report (I think it was something about containercontrols and EmbeddedWindowControl) that they said they would only fix for API 2… which did not make me happy!
But I can’t find it in Issues now.
-Karen
Well, not everything, and as Karen said, there are a bunch of fixes made API2 only.
At the end the result is the same, a lot of time wasted by xojo doing changes nobody asked for and be hated for many instead of bug fixes and real features. Same pattern then, same pattern with api2 and no reason to think they are going to change so Hans-Jürger is right saying it is not worth to invest in a tool that changes just for the whim of one or very few persons without considering the input of the comunity or having respect for the cost of those changes for the users.
Without going into a really long explanation of how things fit together thats entirely possible
However, it would depend on WHAT those fixes are
The stuff at the very lowest level - where the OS API calls are made - unlikely as thats mostly the same code between API1 and API2
Fixing up some new event - possible since thats not down way down deep
So I shouldnt say they cant fix any only in API 2
But ones that matter - where the OS is called - that will likely be the same for API 1 and 2
API 2 feels so much like Y2K
Fix all your code JUST to get exactly what you already have !
Except even thats not true as the API2 stuff has new bugs and issues - some of which were fixed in API 1
So its then fix everything to find out now you have new bugs !
uh … thats not helpful
And in the end how many of YOU are actually copying & pasting code from a desktop control open event to a web control open event - or an iOS or mobile one ?
I can tell you exactly how much I’ve done - ZERO
Not one
Not always. ExecuteSQL vs SQLExecute was a disaster.
yeah we wont go there 
they really should have just used “execute” and “select” but …
those I think they actually changed the plugins but since they dont give us source for anything but Maria I’m not sure
@einhugur or @MonkeybreadSoftware might know that detail
Congratulations, great stats for a presumably small but very engaged community.
I was thinking about anonymous users.
I assume “anonymous” simply means, visitors not “logged-in”.
Then I thought of my own use of the site. I’m mostly logged in when browsing when on my computer, but browse the site anonymously (as in not logged-in) sometimes from an iPad when watching TV with the family.
I wonder then, if you collect IPs, whether the IPs of anonymous users actually in many cases belong to registered users. Just a thought, not that 25% anonymous is unusual, just maybe unusual for a community with a focused user base.
Kind regards, Andrew
We dont claim to have 10 - 20 K users
Several hundred registered users
Yes
yeah the would count as anonymous
TBH I dont think this forum software collects IPs
if it does I’m not aware of it, how to peruse which it may have collected, etc
Personally, I don’t blame Xojo for bugs. As a Mac developer, Apple break one of my apps at least once every 6 months (their point releases are often more buggy than major releases).
I get it, when you have lots of customers, you have to prioritize what bugs need to be addressed and when. What I do feel bad about is that Apple also doesn’t consider my bugs important, and like Xojo, over the years I’ve stopped wasting my time and simply focus on finding workarounds.
I also understand that some bugs are very difficult to fix. I have a bug in App Wrapper, which I thought I fixed, yet one customer is continuing to experience it. I can’t reproduce it (I couldn’t in the first place), but no matter how much I look at the code, I simply don’t understand why it occurs for this customer. I am at a loss as to what to do to fix it. I look at it every few days to see if I can see something different, but I need to understand it before I can fix it.
What irks me the most about Xojo and Apple is that I have no way to get the bugs that affect me resolved, except to not use that functionality, re-invent the wheel or something. I am simply not a priority for either Xojo or Apple. This has detrimental effect on my feeling towards both companies.
Especially as often, I am being forced to re-write code, simply to stay where I am. Taking away time from improvements and adding in more potential bugs to deal in the future. The ONLY advantage to avoiding Xojo or Apple’s frameworks, is that it places me in more control, thus reducing the reliance on either outside entity to solve my customers needs.
Apple doesn’t give a shit if it continues to lose developers, they’re busy finding new ways to extract revenue from the remaining developers, Xojo doesn’t have that luxury, but still appears to act in the same way.
What makes it worse for Xojo is that there is plenty of competition, some better, some worse, but at the end of the day, I can continue to develop Mac apps without Xojo. Heck, even cutting Xojo out and going direct to Apple alleviates an abstraction layer on top of an abstraction layer and reduces the chances of bugs or limitations in a closed abstraction layer that I can’t solve.
A proportion of the anonymous users will be search engine spiders and malware bots. The fewer active ‘people’ the higher the proportion of software bots.
We had to make quite a few changes to update SQL Plugin.
So we got new functions to return RowSet.
And ExecuteSQL vs SQLExecute is because compiler can’t pick a function based on return value and RowSet is not a sub/super class of RecordSet, so can’t use it directly.