Swift GUIBUilder and non-visual components

As many of you know I am creating an IDE to build GUI windows/views for macOS, iOS and tvOS applications. For the most part it looks/acts like many others including Xojo, VB etc.

My current challenge is how to represent a NON-VISUAL component (such as a timer, gesuture etc)

Xojo shows them on a “statusbar” at the bottom of the designer pane. Anyone know how VB displays them?

I was thinking of displaying them the same as any other component, but as a simple icon, but one the can be moved around the screen,

Suggestions?

as far as I remember just as icons within the form. You could move/ place them anywhere as they were not visible at runtime.

Was that how VB did it?

That is the direction I think I am going. thanks

In VS/VB they are below the form, similar to Xojo.

That is VB.NET… how did VB6 do it

If I remember correctly, VB6 did it as Delphi does it. You drag the non visual component on to the form like any other control, and you access properties like any other control, but they are not visible at runtime.

This is what I remember of VB6 too - you dragged a timer anywhere onto the form, it showed a little timer icon in design mode that you could click to access the properties but didn’t show anything at runtime.

Found a screenshot:
image

VB displays them at icons at design time but are not visible at run time.

In VB one can place these anywhere on the form.

Thanks guys…

The problem with the approach of having icons floating around the design surface of a form is that if you have more than 1 or 2 of them, you’re going to have the very devil of a time accessing them. They will clutter up the visuals and you have to put them in some place where they won’t be on top of a “real” form object, etc. Unless you can temporarily extend the form and have them in a row at the bottom, then (remember to) shrink the form height to what you want it to actually be at runtime, this would become unworkable quickly. Meestor_X’s screen shot shows 10 such design time-only controls below the form design surface – in a complex app this would not be unusual.

My own inclination is to create such objects programmatically and manage them in code rather than through a design surface anyway … so long as some 2-way magic doesn’t then cause them to appear on the form after all (or I don’t have to make them a child of the form), it solves the entire question for me.

It would mean more work for developer to create instances of controls programmatically.
My take is to build a container which can hold such non-visual controls.

In Delhi someone has developed such a container (the name escapes me at the moment) which will show all non-visual controls inside it and the container can be docked at any of the 4 sides without affecting rest of the controls and their layouts.

Yes a tray for non-visual components is best from a UX standpoint in an IDE.

1 Like