Control Sets in Web2 Workaround

Noticed a few comments from people saying that not being able to use control sets in Web2 was a huge negative. I agree as I use them a bit, especially search fields above weblistbox columns. The attached project has an example of a workaround that will allow similar functionality

https://1drv.ms/u/s!Ajd-EBIEmPFihDW1d8MkvsRAqAqe?e=SYgB5b

It’s a demo with WebTextFields. I made the ‘ControlSetObj’ class have a super of WebTextField only so I could have the opening event on my class as you can’t use WebControl (it’s reserved).
On the opening event of the instance of ‘ControlSetObj’ on ‘WebPage1’ you just have to call the ‘Init’ method and pass the objects you want in that control set.
Was going to figure out how to add them in the inspector but I don’t think that is possible atm. Might be able to use text name and use introspection to grab the control. I’ll look into that but just wanted to get an example going.
Then you can either implement the event ‘TextChange’ or ‘TextChangeIndex’. I have added both to show how to use it but the ‘TextChangeIndex’ code on the instance is commented out.

Obviously this can be extended for any Event or Control.
Couldn’t make it generic as the AddHandler can’t be used with strings eg/ AddHandler ControlObj, “TextChanged”, AddressOf HandlerEvent. Will submit as a feature request.
Can also change all the WebTextField variables to Variants.
Subclassing WebControl would also make it better as it wouldn’t be on the screen but would have the generic events (currently defaults to 1px by 1px and is set to not visible from editing the inspector behaviour).
You don’t have to have a super for the ‘ControlSetObj’ but then you’ll need to call the init method from the opening of the webpage or container control etc

It is usable, but adding a helper control, adding manually the controls, remembering to modify it if more controls are needed, it is more fragile, awkward and inconvenient. And also not having the IDE advantages like control grouping in the navigator.

Looks like the problem is Xojo imposing a personal opinion instead of listening to the users, not understanding how the feature was used and failing to listen all the users asking for it over the years. :frowning:

Same issue with current control sets in Web1. I do agree with the non-grouping thing. This way is still better than nothing.

Yeah, seems like a bit of culture shift over there recently. Hopefully that mindset is changing

1 Like

I had posted this workaround for Web 1.00 a few years back. It is very simple.

Instead of dragging the control onto the WebPage, drag it into the left pane, which creates a class, where you can add events. Then drag as many instances of that class onto the webpage. They will all trigger the same event in the class. Using the name of the instance, one gets the index (I have duplicated the first member several times).

Here is a quick example:

webcontrolset.xojo_binary_project

I forgot an important detail: since the event will trigger for all sessions, you need to track the session identifier in the event.

Only issue with your approach is the session context is broken until 2022r3 for Web2 (https://tracker.xojo.com/xojoinc/xojo/-/issues/69518 - an issue I submitted and is now fixed). If you needed to access variables, webcontrols etc from that event then sometimes it won’t work

Indeed. A simple solution would be to attach a method on the window. triggered from the class.

What we had to fix in Issue #69518 was the Example, the sessions were working fine.

I’ll upload the updated example into that case, so you can test it with previous versions of Xojo. If you still see issues, we can reopen the ticket.

Yes there was an issue with the example (Communicating between Sessions). But when that line was included back in session communication was inconsistent in 2022r2 and previous versions of Web2. Confirmed to be working correctly on 2022r3_57747.

To replicate the weird behaviour on 2022r2. Open a few tabs in one browser and open the admin page in another browser. If you refresh one of the user tabs from browser 1 you can no longer talk to the other sessions from that browser even if you create a new one.

There was another issue in that example in the LoadSessions method. Give it a try in 2022r2, it should work fine there also.

1 Like