Control Sets in API2.0

General
1

Did something change in API2.0 and the new DesktopUIControl classes and control sets? I’ve always done controls sets like this…

1.) Create your first control in the IDE and set it as a control set.
2.) In code before you create any of your new controls, close that first item in the control set.
3.) Create your new controls.

So let’s say you have a DesktopPopUpMenu call MyList and it’s a control set. In the opening event of the window, I could do this:

Sub Opening

MyList(0).Close

For i as integer = 0 to 5
   Dim mList as New MyList
   mList.top = 50+I*5
   mList.left = 20
Next

End Sub

I have this in a Window where I do this kind of code (but more complicated) but the Control Set is not created. I can create all the controls, add them to an array, etc. but the control set is closed and goes away when I call that first Close command. This appears to be different than the old controls as code that has worked fine for well over 10 years is now broken…

Thoughts?

2

Yes, they are there now.

  • Add your first control to the window.
  • Go to the Cog tag
  • Select “New Control Set” from the Member of popup menu.

That control will be element 0 and you can add others to the set. They didn’t used to be there but they were put back some time ago.

3

I know they are there in the IDE. But I am creating them dynamically. That’s the code that seems to operate differently with the new controls.

4

If you create one control for the group does the rest then work?

5

Jon does it help to know that you can embed controls dynamically without control sets in API 2?

DesktopWindow.AddControl()

6

I did not know that! Thanks, Tim. That actually might be very useful.

And to answer Ian’s question - I can’t get it to work. As soon as I close the first control, it seems like subsequent controls are created just fine but not added to the control set.

7

Well, I think I see what my problem is here. I was trying to create API2.0 control sets on a legacy Window control. That does not work. I was hoping to be able to mix and match legacy controls and API2.0 controls together. Seems like you have to jump all in and convert everything. Maybe you don’t have to but I’ve got other windows that when opened/created have the original window as a property. So looks like everything has to go the new way or everything has to stay old…

8

As I understand Xojo IDE is built using Xojo and Xojo staff said that not everything is API2.0 yet and that will take several years.

My guess is that, depending on what you are trying to do, you will need to convert at least some controls to API2.0 (a Window ‘can’t see’ Desktop controls, only a DesktopWindow, for example ControlCount will be 0 if the controls are Desktop controls on a regular Window).

9

It seems that while you can Add API2 controls to a classic Window, you cannot create API2 control sets on a classic window. The new controls you create just don’t show up!

10

I’ve not checked for controls, however, you cannot have API 2 menus on a non API window or vice versa. I would stick with a window that is API 2 or API 1. That level of compatibility is certainly possible. You can use the IDE to convert a single window to API 2, which is helpful.

11

Yeah so I’ve discovered on that front as well. I saved a separate copy of my app and tried converting all of it. I might try it a window at a time too but given that I’ve had to update multiple sub-classes already I’m likely going to have to update most every window.

But is there any advantage to doing all this work?

12

Unless I’m mis-remembering what I’ve read before, I think the main advantage of upgrading is the following:

  • API-2 controls: Get new features, where applicable, and always get bug-fixes (when resources allow).

  • API-1 controls: Generally, no new features or bug-fixes. In other words, given a lower priority.

Someone please correct me if I’m wrong, but generally that’s what I recall.

1 Like
13

You might want to read this and other similar threads.

14

No, not for working code bases.

15

That’s what I figured.

Was hoping there would be some advantage but to me it seems like the DesktopControls are really a repackaging of the legacy controls. If you have an “Open” even in a window or control, the compiler will say that you tried to implement an event that the superclass has already implemented. So that tells me right there, that Xojo basically created a bunch of new subclasses and called them DesktopControls.

We shall see if the preemptive thread bug fixes get implemented on classic controls as well as the new ones. If they don’t then that would be a reason for me to continue this exercise. Until then, I think I’ll put it on hold…

16

How practical is it to work on API1 projects with Xojo 2024? I’m a-scared it will sneakily and irrevocably convert my projects if I’m not super-vigilant. OTOH I wouldn’t mind enjoying some of the recent IDE improvements I’ve heard about.

17

Even if you stick with API1 controls, nothing stops you using API2 database methods, which have the advantage that you get protection against SQL injection for nothing.

18

Oh I’m already using a lot of those.

The most interesting part about the controls is how there was API2 for classic controls and then they changed it again for the new controls. Trying to look up the documentation for calls under API1 is a nightmare. Really annoying.