Custom look and feel component ID
-
@d-healey So is there Any Quick Fix?
I'm On Bed!!!
Do i Need To Get Up?
Another Sleepless Night? or What? -
@Natan Check github, Christoph has made a load of updates the last couple of days and just fixed the LAF issue.
-
@d-healey ️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️️To The Github No Sleep Nothing, Like My 17 Past Years
-
@d-healey said in Custom look and feel component ID:
I wonder if the issue is something to do with this loop in the drawWithGraphics function?
g->getDrawHandler().flush(); DrawActions::Handler::Iterator iter(&g->getDrawHandler()); while (auto action = iter.getNextAction()) { action->perform(g_); }
Thank You Sir David, For Investigating This :)
I Made This Thread, Reporting This Back In December
https://forum.hise.audio/topic/3375/execution-timed-out -
@Natan said in Custom look and feel component ID:
@Natan said in Custom look and feel component ID:
@Christoph-Hart I reported This Execution Time Out Before
So It Was LAF Mistake?I Made This Thread, Reporting This Back In December
https://forum.hise.audio/topic/3375/execution-timed-outOk, but I don't understand what's the point. Lot's of people reports lot's of things, you're not the only person for this :D
Are you expecting a "Thank You for your report"? :D
Or are you expecting a "Sorry, you reported this last december but it's just been fixed"? :D :DAlso as I see, you write the same thing so many times, and you like to do it :) Just like your magical report, in this thread you write it again and again :D Just an advice, don't do that, it won't fix the issue or won't make you special....
Just be more humble and thank Christoph for this great software ;)
-
@Fortune You Don't Get It :) i Was Waiting For This Fix, And With Dave's Investigation, It Fixed Now :)
You Don't Get It, Man :) I Was Prepared For Sleeping, And Now I'm Building The Latest Version :)
Yeah, I Gifted Already :) -
@Natan Ok after building, good night then :)
But again, I think actually YOU don't get it :D :D you are not the only person who wait for fixes or features ;) -
I‘d say Nathan got the timeouts before it was cool...
-
@Christoph-Hart It was A Nightmare Christoph
I Tried To Explain This In Another Thread, But No One Get It At That Time I Felt Like E.T
Thank You Legend -
The text property of
obj
when applying LAF to combo boxes holds the text of the combo box's value, rather than the text property. This means we have no way to distinguish between different combo boxes (unless we get clever/hacky with some of the other properties). Could we get the text property of the combo box added to its obj? -
@d-healey shouldn’t be hard to fix, I’ll have a look sometime today...
-
@d-healey I just got an idea. What do you think of having a
misc
property for all the components, that is not linked to anything? So it would be just something we can get for any purpose we’d like, thinking of LAF customisation at the top of the list of course.
So just a complementary text property... sounds cool enough? -
@ustk I think we should get @Christoph-Hart opinion
-
I think it might be better to actually include the ID of the component as
obj.ID
- this way you can either use a lookup table or clever name mangling to figure out what path to take in the LAF function.Adding a new property seems a bit verbose to me as it pops up on every component's property editor.
-
@Christoph-Hart I totally agree, but how can the ID be gathered? I tried to add it back in time but then you told me we cannot (easily?) reach the ID from a custom LAF... So I imagine it is not my level of knowledge to implement it, unfortunately
I triedobj->setProperty("id", s.getComponentID());
with no luck -
It would have to go through the JUCE::Component::setName() property - the scripting engine passes the ID as name to the component and the LaF fetches it with Component::getName() and then writes it to the obj parameter.
-
@Christoph-Hart Alright I'll give it a go...
One question though, you said once that accessing variables outside from the LAF is bad. So what about accessing a lookup table like you mentioned right above? assuming the lookup table is declared outside of course. Or should we declare it inside? -
@ustk said in Custom look and feel component ID:
@Christoph-Hart Alright I'll give it a go...
One question though, you said once that accessing variables outside from the LAF is bad. So what about accessing a lookup table like you mentioned right above? assuming the lookup table is declared outside of course. Or should we declare it inside?I've been accessing variables (consts) outside of the LAF functions without issue. I think it might be that Christoph meant you can't pass in additional parameters to the LAF functions... ?
-
@d-healey have you tried multiple instances?
- create a plugin instance with a laf that refers to an outside variable
- create a second instance
- leave both windows open and delete the first instance
This scenario was the most vurnerable setup I could find when debugging laf crashes.
-
@Christoph-Hart said in Custom look and feel component ID:
It would have to go through the JUCE::Component::setName() property - the scripting engine passes the ID as name to the component and the LaF fetches it with Component::getName() and then writes it to the obj parameter.
Oh, is this why
text
is automatically set from the ID when creating the component?getName()
already returns thetext
property, this does not give the ID. Or is there something I don't understand? (what a question Greg... of course you don't...)obj->setProperty("id", "Please fill in the form :)"); obj->setProperty("text", s.getName());
@d-healey Yeah
I've been accessing variables (consts) outside of the LAF functions without issue.
Me too, but this goes back to when I had some crash issues to track down, the access to outside variable was a lead from Christoph. So even if it apparently works likes this, I'm afraid of instability we could prevent... You know, when Christoph says "be careful with this", I quickly get shaking legs