[Help] plugin conflict between locker and tooltip
[Help] plugin conflict between locker and tooltip
i've discovered that, using the locker plugin and the tooltip plugin, if you attempt to update locked text that has a tooltip, the tooltip stops functioning. oddly, the mouse continues to change to the hand, implying that the tooltip should be there even though it doesn't show up.
here is a generator i made to showcase the conflict: https://perchance.org/locker-tooltip-conflict-example#edit
are the developers of these plugins active here? it would be really lovely if this conflict could be fixed somehow :0 thank you all in advance for reading and helping!
You're viewing a single thread.
Seems like
[locker("txt", text.selectOne)]works, it still has a tooltip even after pressing the randomize button.Using the
[locker("txt", text)]doesn't lock the selection since you are locking a list not a single item.[locker("txt", text.evaluateItem)]seems to lock the single item, but the 'function' of tooltip seems to not carry over.right, but i found that this runs into another problem: any randomized features within the locked selection remain randomized and can change upon update attempts, rather than being properly locked.
i've made a second generator to showcase this in action: https://perchance.org/locker-tooltip-conflict-example-two#edit
What is being locked is the entire 'unevaluated' item (since we are using
.selectOne). Unfortunately, evaluating thetooltip-plugininstances seems to remove the tooltip function. Which is why most of the time we are using the.evaluateItemso that only the 'text' and 'evaluated' string is saved, no more randomization, no more perchance syntax, etc, but it doesn't work with thetooltip-plugin.Some explanations which might not explain really well.
For the first one:
- You are selecting one item from the
indirecttextlist withindirecttext.selectOne. - If the item selected is the
[tooltip(...)]it would lock properly. This is because the item to be saved is just that item. - If the item selected is the
[text.evaluateItem]. It would save the[text.evaluateItem]which would then 'evaluate' its text, meaning it would randomize again. Which is why it isn't locking, since what you have locked is[text.evaluateItem]which resolves into random items from thetextlist. indirecttext.selectOne-> then[text.evaluateItem], is selected, then, is locked. Upon randomizing -> locker gets the locked value, which is[text.evaluateItem]-> evaluates to any of items in thetextlist -> shows that the item is not locked.
The item locked is only either
[text.evaluateItem]or[tooltip(...)], the lock doesn't propagate into its items.For the second one:
- You are selecting the
[tooltip(...)]. In which case the whole[tooltip(...)]is locked. - It re-randomizes since you are re-calling the
[tooltip(...)]which would re-evaluate it, or create the tooltip again, in which it re-randomizes the{1-5}that you have to it. [tooltip("...{1-5}", "...")]-> ... (random number 3) ... -> clicked randomize -> recreates the saved[tooltip(...)]which means it re-selects the{1-5}upon display, which results it in not being 'locked' while it is locked.
The item locked is:
[tooltip("this text (random number {1-5})", "This tooltip will not become inaccessible, but the field will not properly lock.")]However, it doesn't appear locked since the tooltip has a 'randomization' with
{1-5}which are evaluated after.yes, that is what i believe is going on behind-the-scenes. neither of the lockers have the issue if the locker is calling
indirecttext.evaluateItemoralttext.evaluateItem. the issue i'm having comes from the fact that currently, it seems that it's only possible to either keep the tooltip functional, or fully lock items including further evaluation; not both at the same time. ideally the two plugins would be able to offer their individual functions together without the conflict.One thing you might be able to do is have a variable that is locked. Then use that variable to determine the tooltip to be used, separating the value from the tooltip entirely, so you can fix the value, then determine the tooltip needed based on that value.
that's a good idea! unfortunately i attempted it in a couple of ways, and it didn't alleviate the conflict. thank you for the suggestion though!
here's a third generator that shows my attempts: https://perchance.org/locker-tooltip-conflict-example-three#edit
Here is what I'm actually suggesting. https://perchance.org/roabyow92m
You have separated the tooltip from being locked. Instead, you have an instance of a tooltip that is outside of the locker. Then, you have the locked store the locked value in a variable. Then use that variable to toggle what tooltip is to be shown on the tooltip instance.
OR
You only have one list, then have the tooltip text as a property of the item that you select (so that the value is specific to that item).
OR
You have a 'template' tooltip text, then only change the part in which would say the stored value.Since I don't know how you've coded your lists, I can only blindly suggest how you could rewrite them. But I've added there some examples of how you could re-write it.
oh! that works really well actually! thank you so much, you've been a really big help! :D
- You are selecting one item from the