This query is really for a Xojo team member. Would it be a massive amount of work and is there a reason why custom controls do not/can not execute in the IDE to allow them to be visible. For example at least allowing the paint event to execute in the IDE would allow custom controls to paint and be visible if they have been created on a canvas for instance.
- it is a fair amount of work
- but it can be done and if you create a WebCustomControl you can see that its possible
- we just haven’t had time to take that work & extend it to custom canvas based controls
Just elaborating a little more as an ex team member. To simply fire the Paint event would never work. If it was nothing more than simple DrawRect commands and such, it would be fine. But the moment you need to call a method, property, constant, or anything else the event would fail to compile since the IDE would only be compiling your Paint event.
So it would absolutely have to be done using XojoScript, like the WebCustomControl does. This gives a pretty safe sandbox so your code can’t mess up the IDE, and allows a more clear definition of what is allowed and what is not allowed.
Plus, of course, the reasons Norman already mentioned.
[quote=56024:@Norman Palardy]
3) we just haven’t had time to take that work & extend it to custom canvas based controls[/quote]
In the past was not the argument that user code could introduce bugs/nil object exceptions/crashes in the IDE that would be blamed on the IDE and thus create a support headache and bad impressions o the product?
That said, I do agree some user code should execute in the IDE. It would help make the IDE be more WYSIWYG when doing layout …
But not just for canvases… Also for setting computed properties in the inspector for control subclasses and container controls.
Consider the case of a container control where you want to assign sign labels to buttons inside the container control while it’s on the the window…
That is just one example…there is all sorts of config type stuff that one could affect how a control subclass (container or not) would looks that one would want to set in the IDE…
It would help make custom control subclasses much more user friendly
- Karen
Thanks Norman/Thom, I suppose what I am getting at is the same functionality you get in VB. I used to develop lots of ActiveX controls and as you probably know these updated in the IDE and as Karen says above this would give an easier way of laying out controls and also anything set in the inspector updated at design time on the control which is what I would love computed properties to do.
Thom, yes I understand what you mean with it not being limited to the paint event but you get what I mean. You mention it would have to be done with XojoScript, does that mean it could be done now with XojoScript by and end user and not Xojo?
No, I mean the only way I could envision this happening in the future is via XojoScript.
[quote=56032:@Karen Atkocius]In the past was not the argument that user code could introduce bugs/nil object exceptions/crashes in the IDE that would be blamed on the IDE and thus create a support headache and bad impressions o the product?
[/quote]
Yes and we figured out how to use XojoScript to make it so you CANNOT do that
Basically “play nice in the sandbox we give you or else”
Spoilsport
The first time you create a custom control with a script to display something that has an infinite loop you won’t be so upset abut it 
Otherwise its “force quit the IDE & start over”