My First Xojo API 2 App

[TheFifth]

Sorry for the long post, but just wanted to vent a bit.

The two Xojo apps I actively maintain are older, starting life back in 2010. I haven’t bothered updating them to API 2 and will never do so as I’ve switched to Swift.

I do however keep Xojo around for quick little utilities I need for personal use.

My main client work is developing web apps using PHP (generally in conjunction with a framework like CakePHP). I use MAMP locally and have several different versions of PHP installed so I can ensure I’m testing against the same version each client has. The issue is that MAMP only allows switching between two PHP versions. You can have as many installed as you like, but it only shows the latest two. You can however rename the PHP folders so MAMP ignores them, so it’s easy to switch versions by simply renaming folders and then starting MAMP.

As I do this a lot I thought it would be nice to have a little MAMP launcher app that allows me to select which PHP version I want to use. Something simple that presents a list of installed PHP versions and dependant on what I tick, it renames all the folders in background and launches MAMP for me.

I was going to use Swift, but I thought it would be quicker to knock it together in Xojo. However, that’s where my unfamiliarity with API 2 comes into play.

It wasn’t difficult to get used to the changes, but it felt like lots and lots of small, seemingly unnecessary annoyances that drove me nuts. A death by 1,000 cuts if you like. It was whilst looking for answers on Google that I came face to face with what many have been saying will be Xojo’s undoing. It opened my eyes to what it would be like for someone who is new to Xojo and what a nightmare finding any usable answers currently is.

I needed the add checkboxes to each row in my listbox. This is something I haven’t done in years, so the way I’m familiar with no longer works (and frankly I can’t really remember how!).

For something so simple, I’ll normally just do a Google search for what I need as it will nearly always bring back the exact code required without having to wade through the documentation.

So I searched for “xojo listbox row checkbox”. This is what was returned…

The first result is from 2013 and uses the old way of doing things that doesn’t work anymore.

The second is badly titled and more about SQL, so not relevant.

The third is from 2022, so more relevant, but it tells you to use:

Listbox1.ColumnTypeAt = Listbox.CellTypes.Checkbox

This gives you the wonderfully descriptive “There is more than one method with this name but this does not match any of the available signatures”, and goes on to highlight the code on the left side of the equals operator when the problem is actually on the right. At this point I knew what the issues was (the wonderfully pointless DesktopListbox), but for fun I pretended I was a true beginner and continued searching for a working answer online.

The first result on Google for a page that’s actually within the Xojo documentation is for the deprecated ListBox.CellCheck, which does at least sub-link to something relevant. I didn’t go to it at the time though as I saw ‘deprecated’ in the URL and didn’t bother clicking.

There are many more results from the Xojo forums, all of which show various methods that no longer work. The first result that is actually for non-deprecated documentation or examples isn’t until the bottom of the second page of results. I can’t see a beginner ever getting that far after none of the code examples on the first page of results actually working.

As none of the first page of results on Google pointed to any working examples or documentation, I thought I’d take a look at the Xojo documentation directly and see how beginner friendly it is. Clicked on search, typed in ‘listbox’ and smashed return. This is where I came across the next issue. If you type fast, the search is broken on the documentation site.

First time through it said ‘No results for “listbox”’.

Second time it took me straight to the reference for the deprecated “ListBox.CellCheck”.

Third time I got to the also deprecated “ListBoxColumn”.

Finally, I realised what was going on, typed like my Mum and managed to get through to the ListBox reference page.

Seriously, what a mess!

I can easily see how all of this would confuse the hell out of someone new to Xojo. Most ‘citizen’ or ‘hobby’ developers won’t read through the dense, somewhat impenetrable pages that the Xojo documentation has now become. They will dive into Google and search for direct examples of what they need.

I know it isn’t Xojo’s fault that Google is showing non-relevant results (well it kinda is actually), but it does show how their constant messing with the language is really damaging the usefulness of their forums and their documentation. I know many have been saying this for a while, but it was interesting to put myself in the position of a real beginner and try to solve a problem by searching for examples.

The new documentation for each item being all on a single page is what is damaging their visibility in Google. Search engines will see the page as being about many different things, not dedicated to one. This is why the deprecated pages that have a single page for each method have better visibility in search. The ‘ListBox.CellCheck’ page is just about checkboxes on rows, nothing else. That makes it very relevant to my search. The main ‘DesktopListBox’ page, that now also incorporates the ‘CellCheckBoxStateAt’ method is about a bunch of stuff, so search engines will see it as less relevant as it’s less dedicated to a particular topic. So I can’t see this Google search issue getting much better unless Xojo start culling the older documentation, which will be painful for those using older versions.

My final rant is a silly one, but for some reason it annoyed me more than anything else, because it just seems so unnecessary and, to me at least, doesn’t make any sense.

App.AutoQuit has changed to App.AllowAutoQuit (or Application.AllowAutoQuit if you’re fully up to date).

Why!?

I get things like ‘AllowRowDragging’ make some kind of sense (even if it is utterly pointless deckchair rearranging) . You are allowing the user to drag that row. You are allowing the user to perform an action.

Auto quit is not allowing anything. If it’s true, the app WILL auto quit when you close the last window. Surely it’s a boolean option that definitely will or will not happen. It’s like text being bold, it either is or it isn’t. Do you ‘AllowBold’? No. It’s either on or off, so it’s bold = true, or bold = false. In my head it’s the same with auto quit. Allow makes no sense in this context.

Anyway… Sorry for the rant, but it’s my first real contact with API 2 and it made what should have been a quick, simple job frustrating as hell.

[npalardy]

A clear statement of the experiences many of us suggested would occur when the API 2 betas first started rolling out with all the renaming
Old examples are useless - but plentiful
Old docs will intermingle with new ones further confusing things

As you note much of this was said from the get go and has been said many times over

But Xojo is particularly resistant to taking advice from their users

[Jeannot]

yep, like me (remember xojodocs.com?) when I noticed that they deleted pages … You can do that (they did) but less mess would have happened with a “permanent redirect” in parallel (which they did not) … But as much as we should not tell them how to run their business, I assume we should not tell them either how Alphabet or Microsoft are running their search engine business :-).

[Torsten_B]

@TheFifth

Finally, I realised what was going on, typed like my Mum and managed to get through to the ListBox reference page.

I questioned the use of the awkward search function and result display in the ‘new’ Xojo. The answer was ‘we opted for the real time experience’. Real time when typing not to fast. The ‘we’ in the answer was revealing.

[npalardy]

That some people pointed out “doing this will hurt results being indexed” at the time fits with

But Xojo is particularly resistant to taking advice from their users

[thorstenstueker]

@Torsten_B

rch function and result display in the ‘new’ Xojo. The answer was ‘we opted for the real time experience’. Real time when typing not to fast. The ‘we’ in the answer was revealing.

Realtime when typing not to fast made my day!

[samRowlands]

No please feel free to rant.

It is easy for us to see that this was coming from our perspective, but I’ve learned over the years that I don’t always see things as they are. So it’s good to see some evidence in how it is for someone returning, let alone a newbie.

If only we’d warned the Xojo CEO that this might happen… Oh wait, we did.

[TheFifth]

@Jeannot

less mess would have happened with a “permanent redirect” in parallel (which they did not) … But as much as we should not tell them how to run their business, I assume we should not tell them either how Alphabet or Microsoft are running their search engine business :-).

Permanent 301 redirects would be the way to go to maintain existing SERP placings and still direct to relevant content, however it doesn’t help those of us using older versions of Xojo as we’d lose access to the older content. Also, most of the search results are for the Xojo forum, so to really sort out the mess, they’d need to cull all of the examples posted there too. Not great.

@npalardy

That some people pointed out “doing this will hurt results being indexed” at the time fits with

But Xojo is particularly resistant to taking advice from their users

Not mashing together lots of content about different subjects onto a single, monolithic page is SEO 101. Keep pages relevant to a single topic to enhance visibility. Maybe sometimes your users’ advice is good? Who knew!?!

@Torsten_B

The answer was ‘we opted for the real time experience’. Real time when typing not to fast. The ‘we’ in the answer was revealing.

@thorstenstueker

Realtime when typing not to fast made my day!

Honestly, I couldn’t believe it when it first happened. I had to double check it wasn’t a one off glitch, but no, it happens in all browsers across different devices. It’s lucky developers aren’t known for their fast typing ability

I’m assuming Xojo didn’t develop the search functionality themselves, but whoever did has done a poor job. As someone who works on web apps day in day out, if you’re performing realtime searches and a user hits return, you never run the search against whatever results you happen to have back at the time. Always wait for the current asynchronous call to finish and see what the full data set is. Or better yet, submit the search string to the server and let it work out what to do. If an async call has stalled, resubmitting to the server can often be quicker than waiting for it to finish.

@samRowlands

It is easy for us to see that this was coming from our perspective, but I’ve learned over the years that I don’t always see things as they are.

It’s true we don’t always see things as they are, but when nearly all of your experienced users are warning you about something, you’d think the penny would drop that there may be an issue.

In an attempt to be constructive and not be accused of being negative for the sake of it, I’ve been trying to think about how this mess can be sorted. None of the ideas are ideal, but the way I see it, the options are:

1. They need to split up those monolithic reference pages and have separate individual pages for each method. If they don’t, the deprecated content will always appear above the current stuff in SERPs.

2. If you must, 301 redirect the old stuff. Although I really don’t want them to do this as we’ll lose access to valuable content.

3. Something needs to be done about the old content on the forums. These swamp the search results and most are non-working. Deleting the posts is not a good idea (which means it’s what they will probably do), so I think the best way would be to append some sort of health warning to code examples. It should be possible to write a script that goes through the forum database looking for code blocks within posts that appear to be API 1 and adding a warning that they may be outdated. For extra bonus points, you could also parse the code block to work out what classes are being used (which you’ll likely need to do anyway to work out if it’s API 1) and link to the most current reference pages within the documentation. It’s not ideal, but at least it would warn newbies that the code most likely won’t work and point them to up to date info. You could just crudely add a warning to all posts that were written before API 2’s release, but having links out to relevant documentation would be a good idea, even for new posts.

4. Stop messing with the language.

There, I’ve tried to be constructive about the situation. I’m sure it’ll fall on deaf ears.

[TheFifth]

I’ve been thinking a bit more about how I’d approach the issue of code samples on the forum. I still think warnings and links to documentation would work, but I don’t think I’d write a script to update the database directly.

I think it’s best to do it on display, so as the user reads a post, each code block is sent back to the server for parsing and links out to documentation are appended below each one. This could be done lazily to prevent excess parsing, so the async calls are only made when the code block scrolls into view. Discourse lazily loads posts anyway, so you may not even need to worry about this. Just watch for DOM changes.

Parsing could be as easy as checking for a predefined set of keywords and whenever it finds one, append a link to that documentation page. You could avoid simple stuff like operators and control flow structures and only link the classes.

In terms of API 1 warnings, you could keep it simple and just have a cut off date where everything prior is flagged with a warning. Or if you want to be clever you could check for all API 1 specific keywords, or any references to old controls (like ListBox instead of DesktopListBox).

The advantage of doing it on display means that any new code posted would pick up links to relevant documentation, which I think is a good idea in itself.

I know this is all pointless chit-chat and because the idea originated here, it will never be accepted, but I thought I’d share my musings.

Anyway, I’ve got work to do. Enough time spent thinking about how to fix someone else’s issue!

[Jeannot]

@TheFifth

Permanent 301 redirects would be the way to go to maintain existing SERP placings and still direct to relevant content, however it doesn’t help those of us using older versions of Xojo as we’d lose access to the older content. Also, most of the search results are for the Xojo forum, so to really sort out the mess, they’d need to cull all of the examples posted there too. Not great.

Oh, sure! I am not saying 301 is solving anything. All I tried to say is that if someone has the weird idea to delete anything on the internet then use at least a 301 redirect. Every 12years old knows this in 2023.

xojodocs.com (obsolete, see link below) was a little web2 app to analyse their former documentation systems (how many articles per topic, metadata, oldest articles, new ones, sizes, etc, etc.). An own backend parsed their pages once a day. And one of the first observations I had … look they are deleting docs (bumm, beng, zack). Of course no user might have linked other documents, so yes, brilliant let’s delete them

Anyway, I’ve got work to do. Enough time spent thinking about how to fix someone else’s issue!

Exactly, best possible choice, considering the circumstances

What happened to xojodocs.com?

[TheFifth]

@Jeannot

All I tried to say is that if someone has the weird idea to delete anything on the internet then use at least a 301 redirect. Every 12years old knows this in 2023.

Maybe the problem we have is that those controlling Xojo aren’t 12 years old?

[MGD]

This whole story rings so true. As a hobbyist developer (mostly, though I do some toll building in Xojo for my paying job, so in that sense, I’m also a citizen developer), I enjoyed being able to work on a hobby project and using my over 20 years of code and experience with Xojo to make it so I could just get things done. It was fun and satisfying to build what I wanted. The Xojo bugs were annoying, but always something that could be worked around (again, that big collection of code). Slightly more annoying was reporting bugs and having them closed as not reproducible or never actually fixed, but, whatever. Is what it is and I could still have fun being productive in my precious spare time.

But, API 2 changed all that. Start a new project, and much of the old code is broken. Worse, a lot of the 20 years of experience is now broken, as well. To add insult to injury we have the new documentation which is constantly annoying. I know it’s just a matter of going through some conversions and then learning the new framework, but I’m a hobbyist. That is neither fun nor rewarding, and really, I don’t have the time for it. If I’ve got to make that much investment, maybe it’s worth a little more effort to just learn something else, with a lot less frustration redoing old stuff and worry that there’s some other big change around the corner. The sad fact is, I get more satisfaction spending my hobby time investigating the alternatives, tinkering with them, and considering what’s possible than being constantly reminded of the API2 verbosity and annoyances with the documentation every single time I look something up – not fun!

I still can’t discern from the various discussions if Xojo think they are targeting pros or citizen developers and/or hobbyists. If this change made things somehow better for Pros, great – hobbyists are just collateral damage. Or maybe the thought was it would make Xojo so much better that it will become attractive to a whole new wave of pros and hobbyists, so a few losses can be tolerated in the near term. But, if the business model is hobbyists and citizen developers, I can’t for the life of me figure the value proposition in API2, and I don’t imagine there are waves of new developers looking at Xojo for pro or hobby use. I work with a lot of young developers, and I don’t know a single one who has ever heard of Xojo. The tools they use are completely different; I just don’t see any way any of them would pick up Xojo on the side, let alone for the paying job. I’m clearly missing some key business insight here, but time to get back to tinkering with other tools.

[Karen]

@MGD

If this change made things somehow better for Pros, great – hobbyists are just collateral damage.

That seems not to be the case…

Or maybe the thought was it would make Xojo so much better that it will become attractive to a whole new wave of pros and hobbyists, so a few losses can be tolerated in the near term.

Perhaps that was the theory for new hobbyists or citizen developers but it’s hard to see how anyone could think API 2 would make make teh product more attractive to Pros…

And I doubt it would be be a significant plus for new hobbyists or citizen developers, and it’s certainly a negative for those of us who have used the product for over 20 years…

I can’t for the life of me figure the value proposition in API2,

The risk/reward ratio looks to me that it should have made API 2 a non-starter…

Geoff is the only one to know how it’s actually working out.

-Karen

[npalardy]

@Karen

Geoff is the only one to know how it’s actually working out.

He’s not been very forthcoming about much
Maybe XDC in London will shed some light but I suspect it will be

Look at all the bugs we fixed !
never mind all the new ones that got created along the way

Look at where we’re at with Android
uh ? its been in open beta for probably 18 months now ???

and a lot of other platitudes that ignore the problems they’ve created in the last few years

oh well

[ivan]

@npalardy

Look at where we’re at with Android
uh ? its been in open beta for probably 18 months now ???

Working for free as a tester/QA is one thing, but having to pay for it having a current licence is another $#%*!& idea

If they dont have enough “testers” that actually know android OS/Apps (or “testers” in general) those 18 months is another huge waste of time with more “we dont saw those bugs” and “its to late to change is now”

[bgrommes]

@MGD

If [API 2] made things somehow better for Pros, great – hobbyists are just collateral damage.

I came in after API 2 but from what I can see, no, it didn’t help us pros, either, at all.

When Python made breaking changes going from Python 2.x to 3.x, they were fixing real inconsistencies in the language and I’d argue they were way more justified changes than in Xojo. But apart from that, even if you disagreed with the breaking changes, they maintained and even improved Python 2.7 for something like 10 years to give people time to make the leap and arguably for many projects after that long it needs a rewrite anyway.

What makes that parallel even more irritating to me is that Python is an open source endeavor, it is not like it had Microsoft or Apple behind it. If Xojo Inc really had this grand vision to move things forward into the future they could have pulled it off as well as a bunch of FOS volunteers, if they really wanted to.

[Torsten_B]

@bgrommes

I came in after API 2 but from what I can see, no, it didn’t help us pros, either, at all.

Dividing x-platform development into desktop, mobile, web etc. code silos is a marketing approach and is the antithesis of x-platform development.
I guess they did not do a proper risk assessment or ponder the potential consequences from a developer point of view before making the move. Now they find themselves between anvil (lack of resources) and hammer (frustrated customers), which is an undesirable position.

[Jeannot]

@Torsten_B

hammer (frustrated customers)

hammer (frustrated FORMER customers) - what is even worse … sh$tstorms versus cash flow - brilliant “strategy” … risk assessment via reality …

[SteveW]

@bgrommes

When Python made breaking changes going from Python 2.x to 3.x, they were fixing real inconsistencies in the language and I’d argue they were way more justified changes than in Xojo.

I think the nature of Python helped here too. I had a number of Python 2.7 scripts and in most cases getting them to run with Python 3.x was as simple as updating the import statements to: import x as y
e.g:

if(sys.version_info[0] < 3):
    import ConfigParser
    import urllib2
else:
    import configparser as ConfigParser
    import urllib.request as urllib2

[npalardy]

@Torsten_B

I guess they did not do a proper risk assessment

indeed its easy to see they dont
https://tracker.xojo.com/xojoinc/xojo/-/issues/71075

there are other examples of changes that break code