If you are going to add controls “on the fly,” what use is an GUI Builder? The whole point is to be able to layout your controls and visualize the results ahead of time…
Besides… controls added “on the fly”, simply append to a control-set… so that concept is STILL there
WTF??? In my case, 99% of the usage for contol sets was NOT for creating more controls. 
Controls sets have never (at least for me) been primarily about adding controls.
Having control sets where the events have indexes is a great way of managing groups of related controls of the same type conveniently. Doing it that way is less coding and is very helpful, just as it is for menuitem sets created in the IDE and only needing one Menuhandler for them!
Just because the CURRENT engineers don’t use controls sets that way, maybe they think no one does?
Or maybe they just lost the vision of whomever created the mechanism originally, and don’t think about it outside of creating controls on the fly?
-karen
GEOFF SAYS DON’T DO IT!
damn, why doesn’t anyone understand, Geoff is the more knowledgable member of the Global Information Technology community… If you can’t see HIS vision, and can’t follow HIS rules, than perhaps using something other than HIS product might be in order?
OH WAIT! that is what many of us have already done.
His Vision is 
His Rules are 
and his product? well enough said
Will this be part of API3 ? 
There is an error in this sketch: It should not even have edged weeks…
Wheels on the sand is a bad choice. That is why ancient Ægyptians used a skid to transport stones for pyramids…
That said, this is funny, thank you.
I consider myself being an advanced citizen developer, having coded in C and 68k Assembler at University, moved on to other activities that did not involve coding and came back to writing my own applications because IT could not deliver. Having done a number of apps in Filemaker in the last 15 years, I am looking for a new platform because the old one has persistent issues and limitations.
While Xojo looks attractive at the beginning, the whole process of getting proficient in writing Xojo code ist hampered by a buggy and incomplete documentation that has a clumsy search function and the many bugs in the IDE. Spending too much time finding out if my code is wrong or if it is a bug in the platform. Discovering that most confirmed bugs do never get fixed, I have stopped the whole thing for now.
I am the type who works and learns using secondary literature. There is nearly none for Xojo API2 because of the unfinished work on API2 that delays updates of AP1-based works. So no secondary literature available yet.
The ‘average user’ is a marketing term that lacks statistical evidence (none has been presented). A more realistic approach would be ‘we have users of all levels of knowledge. We have users of different levels of activity as developers, spanning from part-time to full-time. From the hobbyists to those who earn a living with coding’. Many more categories apply.
When start working with a platform, most people are looking for help and inspiration from more experienced developers. People’s knowledge and skills grow over time. If platform does not have top-notch developers helping others, showcasing the platform’s capability and pushing the evolution, the ‘average user’ will quickly hit a wall and lose interest, because they are not ‘fed’ and inspired.
Many of those have left Xojo’s forums
I know of several that have simply moved to other languages / toolchains
I started coding before the web became a really big thing and so I was mostly self taught from what I read in the manuals, as well as by doing. I went along that way creating some solutions for over a decade with various languages, though none were object oriented.
When i starting using REALBasic over 20 years ago, it was on those mailing lists that I had my first contact with “pros”. The signal to noise ratio was pretty good and I learned a lot.
If that was now, It would be a different story. The depth of many of the discussions on the forum simply are not what they once were in the community.
-Karen
In most cases API 2 does not add any value IMO… Yes a few things in API 1 could have been named better, but for the most part I thought the balance between readability and brevity was a good one in API 1…
AND for me personally the long names make code LESS readable, because I can’t absorb long lines of code nearly as quickly…
If I wanted to learn COBAL I would learn COBOL! 
(I have never seen COBAL code but I have heard it’s very wordy!)
-Karen
It is Karen.
Objective-C is very wordy too. I find it really helps when over viewing old code as it makes it quicker and easier to find the specific documentation for that API.
This is where being able to arbitrarily split lines onto multiple lines can help
Xojo permits it but you always have to toss in the _ at the end of line
(not perfect but better than not supporting long lines at all)
Personally find long lines that are all one case (lower or upper) the worst to read
Mixed case, usuall camelCase, is one I find easier to read
But since Xojo doesnt enforce that it can get messy esp with multiple devs
In the past there where courses, many blogs and tutoriasl. Xojo has become very good at killing those to. The stupidity of renaming all for example, no value added but not wort it to recreate all the content of courses and blogs.
Renaming everything killed the value of most back issues of xDev
Just one example of how they hurt their partners and customers in one shot
Well, yeah. xDev is a good example but all 200+ training videos and 10 years worth of blog posts were pretty much thrown out overnight. Many people said, “Oh, just redo them for API2,” without realizing how much work that would be. I used the training and blog as marketing material for Xojo consulting. I have even less incentive to do it now that I’m not doing that any more.
Yes your training site also got crushed
My bad for not mentioning that as well
Probably 2 of the bigger resources that existed
It hurt partners - those who tried to help promote & “spread the word” like your blog & videos
And customers. There’s still frequent confusion in posts where people have munged api1 and api2 code, web1 code and web2 code
And this made the docs even less useful
It hurt everything in one fell swoop
And it’s not like we didn’t bring up these concerns early and often. But the smartest guy in the room knew better.
