Survey: Should Xojo bring SDKUIControl to Desktop like Web 2.0's WebSDKUIControl?

Wouldn’t it be great if we could also get a visual SDK class for desktop projects, like the one that has been available in Web 2.0 since 2020r1?

This class is called WebSDKUIControl and has an event

DrawControlInLayoutEditor(g As Graphics)

This allows drawing commands to be executed directly in the Xojo IDE, thus displaying the control in the layout editor. It would be great if this functionality could be made available to desktop projects (including TextInputCanvas !).

What do you think about this? Would you also like to see this functionality in desktop projects?

  • Yes
  • No

0 voters

The IDE would have to RUN your code in the IDE.

Or it could use a XojoScript to draw a representation of your control - but that xojo script probably would not be run at runtime to draw you control so it might look different than it did at design time.

That is correct. It’s a XojoScript with a context that has access to the properties and constants in your class. The code is not used at runtime.

1 Like

Just for effect of comparison with other solutions;
In some other platforms, people create “Visual Components” using special features of the language, compiled, not scripted, so almost all actual code of the real component is used, so we can even see “real time” simulations of the real results at design time (change properties, see the results, even populate controls with real content). You first compile your component, then “install it” in you palette of components. A component starts from a Class, a non-visual one starts inheriting from a non-visual base class, like a Component Class, and a visual one from a visual base class, like a Control Class (inherited from Component). Besides the usual private, protected, and public accessors, there’s another one used like public, but that shows up in the properties panel, some of them call it published. Once you change a published property (a design time property) you run a setter code allowing to redraw the component to show a reflection of such change, the visual component base class has design time capabilities to reflect it at design time, in the design editor, the “equivalent” of a run time behavior in a run time window. They fire component events at design time, like move, resize, redraw… Components are a kind of loadable dll with design interfaces, that when your code is compiled, the design code part is discarded and resting just the run time code statically linked. The “stripped” code, equivalent in Xojo, would be something like #If DesignTime Then // runs at design, but will be stripped off on the final compiled code.

1 Like