I have a couple of questions that the documentation doesn’t answer.
Is it possible to set the initial width or height of a control in DrawControlInLayoutEditor, apparently not. I am surprised because it looks like the WebSDK controls are 34 px high, but many other controls are 38 px.
SessionHead looks like it will be called first, which makes sense, but before properties can be read. If, for example, I want to give the user the option of choosing whether certain things should be carried out or not via a property, then this event fires too early. I would have to solve that as JavaScript and DOM manipulation. That is also possible, but why is there this event, I think that I am overlooking something.
You should set this in the Inspector Behavior dialog, then, I believe, validate and correct as needed in your TypeScript, but you should try to match user expectations.
This is meant more for loading document-wide things like CSS and JavaScript files. When properties change you should be sending that to your TypeScript class for update and render.
You are right, but it is the place where the user is “designing” the layout, right? So it would be nice that the control has initially the minimal height and width the developer is expecting? Xojo is doing that, as controls have different heights, but it seems that the IDE doesn’t let us do that.
It’s not a big pain point, at max a nice-to-have and mainly I wanted to be sure that I didn’t overlook some trick or hint to force the IDE to draw the control initially in a certain size. Seems that my acuity is still good enough .
My acuity isn’t so good, overlooked your response. Great! Never tried that, probably because the Inspector Behavior not always behaves like I want, It must drive you sometimes nuts with graffitsuite, doesn’t it?
Actually, no. I don’t have any issues with it, really. Sometimes if I change the API of a component I get some funkiness, but not a lot otherwise. If you’re going to build components for others, get used to the Inspector Behavior dialog.
Yes I know, but think you want to give the user the option to select which version should be loaded (Font Awesome for instance), you can’t interact that event, as the properties are not yet available, so you need to handle it in TypeScript. Here again, I was not sure if this is by design on purpose. Because if it is on purpose, I am asking myself why, as we could always handle it in the constructor in TypeScript, okay it might be easier for some.
You really shouldn’t do that. Giving users options like that can conflict with other libraries. As an example, GraffitiSuite loads FontAwesome5. Your control loads FontAwesome4. What will they get when they use a class that overlaps? The problem is even worse when considering JS library versions.
Granted, bad example ;-). I’m trying a better one: thing of user can chose to use a font awesome icon to an own SVG. In the latter case I don’t need to load font awesome, right?
Lucky you. I had a few. It seems I have to save sometimes the project, close it, reload it for some changes to apply. Default values in properties are sometimes taken over to Inspector Behavior, sometimes not. I haven’t seen the logic why this is happening yet. But most importantly I had sometimes the issue that “default” properties “moved” into my section, and I wasn’t able to get them out other than editing the physical file.
Anytime I’ve seen this, collapsing the WebPage or Window containing the control and selecting something different in the navigator, then going back to that control typically fixes it, but I don’t see it very often at all.
Again, I know. That’s actually the challenge in my example. Think of a user who can decide to either use an SVG or a Fontawesome Icon. If he adds SVG Data, I would not need to load the font awesome resources. But as I can’t analyse what the user did I have to load it even for those, who don’t use it. Not a big drama, but I don’t like to load resources in a plugin, which the plugin doesn’t need. Even with caching, I think we should avoid to load unnecessary stuff as much as possible. Anyways, you answered my question it is not possible.
In that instance, it would probably be best to have them provide the full SVG source in a string property. Otherwise you’re doing a lot of work in the browser for that icon.
Yes, I was more surprised that in “SessionHead” we can’t access the properties yet and I was wondering why, probably for performance reasons, as you want the resources to be loaded asap.
SessionHead fires once per session when the browser first connects to the app so that your custom control can request any libraries that it needs. As you have discovered, your control does not exist yet. In reality, we create a temporary instance of your control just to be able to fire the event, which is immediately thrown away. The same is true for SessionCSSURLs and SessionJavascriptURLs.
Further, DrawControlInLayoutEditor is just for drawing the existing control. As Anthony stated, it’s a XojoScript Graphics context which interfaces with the IDE layout editor, but does not have the ability to write values.
, but really cool.
.