Xojo Documentation is useless

This is the very first time I have ever had to explain it. And it’s the built-in icon set. It’s not one we created.

I think this is a very misguided initiative. You’ve stated on numerous occasions that your target audience is the somewhat less-advanced coder. One of the most appealing aspects of Xojo for newcomers is the drag-and-drop WYSIWYG GUI editor. Creating controls at runtime, while of course very useful and powerful, is the antithesis of the WYSIWIG GUI creator. It’s an advanced technique. Control sets are extremely useful for beginners and experienced programmers alike, whether or not someone at Xojo thinks that runtime-created controls are cooler. Xojo is supposed to be a RAD environment. Whipping up something with a control set is often quicker for an in-house tool, proof of concept, etc. IMO Xojo should in general refrain from offering subjective opinions about how users should or shouldn’t code in the documentation. Tell us what it does and how it works. You don’t know everyone’s situation and application considerations.


What is the difference? And where did you tell users what?

1 Like

Yes, Python uses a different search results experience that is not real time. We chose to go with the real time experience.

I thought that is what a control set in Desktop was under the hood, an array of controls?

Also it’s very disappointing that that a control array isn’t supported in Web 2.

1 Like

That is inaccurate. I’m quite sure I have never said that. Our target audience is anyone who wants to create apps fast. Some are hobbyists, some are citizen developers and some are professionals. Even amongst these three groups, the experience and skill level vary quite a bit.

Our goal is to help users be successful. Sometimes that’s developing new features and other times it’s helping them understand good development practices and techniques.

It would seem that way but no, that’s not what they were. What are you trying to accomplish in a web app where a control set would have been the solution?

endless discussion because a search need more input than one textfield … :exploding_head:

1 Like

Gosh the last time I wanted to use it was probably over a year ago when testing web 2 features and I moved on and went a different design direction. Since I know it doesn’t work for Web 2 apps I consider it out of my toolkit, but if it was there I likely would consider it for future apps again.

They have different uses cases… That Xojo inc can’t seem understand that is very disheartening… to say the least.

  • Karen

That completely defeats the very purpose of the IDE. Control sets can be created in the IDE, whereas arrays of controls have to be created in code.

In a control set, event handlers are common to all members. Doing the same with an array of controls requires some doing.


How are control sets bad practice? They certainly help with Xojo being WYSWYG RAD , at least IMO.



When did you say this? And can you share a very good reason why to use arrays controls instead of control sets? Arrays controls are counter productive (to say the least).

Would you like to tell me how to do that, with the IDE, and Menus? As far as I am aware there is no way of doing it. Without writing any code.

Completely agree…

At times it seems Xojo inc looks at features as if there were for use in a specific app they are writing, intend of being a tool sets that that we uses in many different ways with different needs and situations, that they never though about.

Robust features really help with that BTW.

  • Karen


Been there… tried to remove a couple of features from my app that I was sure nobody was using. Boy, was I wrong…


But It’s not the first time that it has needed to be explained on this forum. Even I found myself skipping over that first item because it didn’t look meaningful to me. I mean, who thinks that # followed by a curved arrow means “go to this topic by pressing the return key”. If you’re a web designer that’s familiar with html, you might recognize the # as being an anchor, but even my brain couldn’t make that leap.


Boy, I really hate continually bashing the new docs because I know Xojo put a lot of time into this, but here’s another example of long journey for something that should be simple.

I know there is way to return screen count and resolution and I want to view the docs. So, I search: “Monitor”, “Display”, “Screen” and…

These seems logical for a user to search these terms as it’s possible that the user will refer to their screen as a monitor or display. Why doesn’t searching for “Display” result in seeing something useful, such as desktop.display?

Conclusion for me on this is that Xojo has put their faith in users finding the necessary info to use their product at the mercy of a VERY bad algorithm they cannot completely control.

But you’d never have to get to that stage in the old docs because typing anything from “g” to “graphics” lists graphics as the first result so you’d never and up in a further search, unless you just fixed that too? Type g then gr then gra into the new search and see the disparity in results and reduction in productivity compared to the old search.


OK, apparently there was a misunderstanding on my part about what should and should not be documented about Control Sets. It used to be that Control Sets were the ONLY way to add controls dynamically and that’s no longer true. However, as has been pointed out, they are useful when you want to share properties and events amongst a group of controls. Thus, I’m updating the Control Sets page (which even in the old docs was out of date) so we can get it into the new docs.