This thread is starting to get interesting;
Well, well, well … first snowflake in hell:
So Geoff finally relented to better judgement - kudos on that.
But I would have been more impressed if he had simply said that he didn’t fully understand how control sets could be used (which happens a LOT with Geoff - he is in way over his head) instead of calling it a misunderstanding about documentation … that’s a
What I do not understand: did none of his employees take him aside and explain it to him? Or did they not understand it themselves (which seems unlikely)? Or is it Xojo’s culture and nobody dared to tell him it is idiotic to remove control sets?
maybe they just never read that thread ?
maybe they fear doing so - he DOES sign their paycheques you know
lots of possible reasons
When they first said Dynamic Control sets were the way , and not to use Control sets, I and others tried to explain why dynamic control creation did not replace the functionality of control sets, as they were not just used to created controls on the fly… that was only one feature of them…
But it fell on deaf ears… I suspected the engineers there now (or Geoff?) simply did not use them that way so did not see the utility… I though it might be a case of forgetting why they were designed the way they were.
I mean, who’s left to say ‘no’ to Geoff? Joe, Norman, and Greg are all gone. Seems like Greg might have been the last one to really put his foot down on some of this stuff.
Is his statement that “Control Sets used to be the only way to add controls dynamically” even true??
Unless you count container controls, yes.
Really? You couldn’t instantiate, say, a pushbutton in code and embed it in a window?
You could through an undocumented call, but it was super janky, I guess they just cleaned that up.
Not in a supported way.
X-Platform or just Windows? Using declares or pure xojo code?
In my 20 plus years of using the product, this is the first I heard of that. It obviously was not documented or supported.
Cross I think, I only ever played around with it under windows, add this to a button on a window, oh yeah that’s also how to find a control by name without making a dictionary or using introspction:
_AddControl("Hello", New Label) Static o As Label = Label(_ControlByName("Hello$0")) o.Text = "Test" o.Width = 200 o.Height = 22 o.top = 20 o.left = 20
Use at your own peril.
Yeah, super undocumented, but AFAIK that’s what Xojo actually uses underneath to build the UI as it doesn’t use NIB files.
There’s a ton of stuff in the Xojo framework that’s “Private” which could help customers build better apps, albeit the same can be said for Apple also. Sleep Aid has to use Private API, because the public API can and does fail.
The only “janky” was the call itself was undocumented
Everything else, including sizing etc adding handlers etc all worked perfectly
I suspect thats what they cleaned up and revealed
The border wasn’t visible in Windows and I think it was offset in Mac. No amount of HasBorder made it appear in Windows. I could have spent some time looking in to it, but it was undocumented so I didn’t bother.
Cant say in any places I ever used it on macOS I noticed it being offset
Never didi it much on Windows except to say “not worked them same”
Clients didnt have windows products so there was no need there so it certainly could have been slightly janky and I not might have noticed
FYI… .It is 100% possible (and supported by MANY developers) to create macOS and iOS GUI interfaces without the use of Interface Builder/XIB/NIB. It is something I do ALL the time,
It is also possible to do it not using Auto-Layout as well
I was even taught a declare that could create the correct class based on its name stored in a string. Sort of like
Var ClassName As String = "MyClass" Var Instance As New ClassName
The syntax wasn’t actually that simple, but it worked to an extent. Joe warned me that it’s super sketchy though. It was experimented with in the early WE days to try to build universal object serialization. And, of course, unserialization.