Have the "data" object from ScriptPanel on any ScriptComponent.

[jonhallur]

@d-healey I already agreed with you, no need to take me to school. :)

In my case I would just need to have object one level deeper with a list of on and off state.

g.fillPath(Paths.icons[obj.text][obj.value], obj.area);

And I agree, it is an elegant solution.
My mind is just already committed on the data object.

[d.healey]

@jonhallur said in Have the "data" object from ScriptPanel on any ScriptComponent.:

In my case I would just need to have object one level deeper with a list of on and off state.

This isn't necessary, let's keep our designers out of the code :)

You can use the text property for all kinds of magic. For example you could put on icon,off icon and in your laf function you can check if , appears in the text and if it does you convert the text to an array using join and now you can use the button's value to get the correct icon name.

My mind is just already committed on the data object.

Sometimes it's easier to change the way the system works instead of changing the way the programmer works :p

Edit: Oh I just noticed I have some implementation of that in the link I posted before (it's not as nice as the solution I just suggested though) - https://github.com/davidhealey/LibreWaveBoilerplate/blob/master/LookAndFeel.js#L293

[jonhallur]

You can use the text property for all kinds of magic. For example you could put on icon,off icon and in your laf function you can check if , appears in the text and if it does you convert the text to an array using join and now you can use the button's value to get the correct icon name.

String parsing in every draw call ?
Now you are just asking for bugs :)

[jonhallur]

This isn't necessary, let's keep our designers out of the code :)

@lalalandsynth straight from the horses mouth

[d.healey]

@jonhallur

String parsing in every draw call ?
Now you are just asking for bugs

There shouldn't be any issue with this, it's all happening on the UI thread (and I've been using it in a lot of projects :) ). There was a post a while ago from Christoph that warned against using external data in LAF functions, not sure if this also applied to local LAF. I'll see if I can find the thread.

Edit: Here it is - https://forum.hise.audio/topic/3228/look-and-feel-toggle-buttons-and-the-midi-sources-panel/26?_=1671280536688

[lalalandsynth]

@jonhallur I would have to agree :)

[jonhallur]

There shouldn't be any issue with this, it's all happening on the UI thread (and I've been using it in a lot of projects :) ). There was a post a while ago from Christoph that warned against using external data in LAF functions, not sure if this also applied to local LAF. I'll see if I can find the thread.

Edit: Here it is - https://forum.hise.audio/topic/3228/look-and-feel-toggle-buttons-and-the-midi-sources-panel/26?_=1671280536688

I know I am confusing the LAF for buttons draw functions and the setPaintRoutine() for panels, I know local LAF functions would not have access to the data object and this like the ScriptPanel functions have.

If I could access the data object in a LAF call that would also mean I wouldn't have to use external data, like he warns in this post.

[ustk]

@jonhallur I’m currently using external paths inside LAF, so I imagine this falls into the forbidden zone… What about colour constants ? (like Coulours.red) aren’t they considered external too ?

So perhaps in this case populating a data object prior to the LAF would make it more stable, if any of the above can create instabilities of course.

As for the relevance of a data object regarding the programming workflow, I can understand the importance of it though I don’t feel personally concerned (at least for today)

[d.healey]

@ustk I'm using some external data too in my LAF functions and haven't noticed any issues. I wonder if it was just Christoph being cautious or if the issue was fixed.

[Christoph Hart]

It's still a good advice to avoid using external data if possible, but I did in fact work on some multithreading issues since I posted the warning so yes by now it's safe enough to use static preallocated path objects in a LAF function.