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.
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.
Thank you.
That said, since control sets do not exist for Web, arrays of controls remain useful there.
Not even typesense use that #enter method on their own site.
Enter should return a list based on your entered string, if typesense cant do that then its the wrong implementation.
For a tutorial on how 99.9% of the world thinks and knows how to use search and how search works, see google.com
And people has being asking for years now when the Control sets are going to be in Web 2.0. It is the main reason not to migrate for some users
…
Of all the topics related to control sets, I dindt see a single one related to create items at runtime, but about having a single event and/or having a better experience on the IDE.
When I asked about in Web I was pointed otu to Simplified: Adding User Interface Controls at Runtime – Xojo Programming Blog
How is it “simpler” or “better” or any “good” to create a extra container, add a lot of code and not have a preview VS just add the controls in the IDE?
Having 20 controls to reuse, Create them in the IDE, manage them in a single event handler and iterate with the index, have a better IDE experience by not having code in 20 events. It was EASY, now thinking about doing all the design in code plus having code on 20 events makes me avoid web2 only by this lack of functionality itself
And by the way, Not having control sets on web, not only makes things worse, dificult and verbose, it is even broken:
https://tracker.xojo.com/xojoinc/xojo/-/issues/69680
Xojo said that Control sets on Web 2 Were “deffered”, maybe many users are still waiting for them. There is also a Feature Request:
I’ve got “monitor” and “display” now going to DesktopDisplay. I’m working on Screen which is a bit more difficult.
Awesome, thanks Geoff!
I’m pretty hopeful control sets will return to WEB 2.0 but I’m willing to wait a bit more as the major pain points are fixed (I like the recent progress on the essentials).
About the documentation, yes I feel it would be hard to onboard to Xojo using Google to find solutions.
Google also seemed to give better answers 3-4 years back too.
Anyone ever read the Visual Basic 6 Black Book? It was a compendium of “get r dun” examples.
Arduino even has examples I copy and paste from all the time. The library manager with user submitted / vetted libraries are a god send.
Xojo’s built in examples are pretty good though but need some expansion for specific applications.
I vote for more documentation to come in the form of built in examples or even something like Arduino IDE: a searchable database of sample projects from reputable users.
Ok Screen now takes you there as well. If you find more things like this, please create an issue and include whatever info you can. I don’t want these to get lost in a forum thread.
@Geoff_Perlman Thank you for adding back Control Sets to the documentation. I would still like it to acknowledge that a static menu arrangement that wishes to make use of a shared Menu Handler is another valid use for Control Sets.
Thank you.
For the record, I have been using control sets for the last 15+ years and have never once used them to create controls on the fly. 2 very different use cases.
Oh, and thank you for your efforts to continue to improve the documentation.
I don’t mean to pile on here, just a tip for others. One specific use of control sets is with the labels that you put in front of every control on the window and never change in code. If you make them a control set, it really clean up the list of controls. You only have one entry for all of them. If you decide later to change one in code, simply change its name and you’re good to go.
I think Ivan’s point is important. There is no scenario where an old deprecated control or method should appear before the newer, maintained and likely more relevant one.
Ideally there should be a checkbox to toggle whether deprecated results are shown or not. Can’t this be done with some client side Javascript?
We chose to go with the real time experience.
‘Real time experience’ means incremental search vs delimited search, like implemented in Python docs.
The disadvantage of the implemented real time experience is that a search result cannot be stored or reused in any other way. One has to retype a search over and over again. This does not save time but costs time in usage.
What is the advantage of this real time experience over a delimited search in Xojo docs?
