Strange Undo/Redo behaviour

[flucatcher]

Hi

I have the same problem and have posted about it in the forum:
viewtopic.php?f=9&t=1066

Some workarounds:
I don't use toggle buttons anymore, I use normal buttons and manage my own state.
In case I have tabs (for two oscillators in the same UI) I make sure I have trigger undo / redo actions when changing tabs.
In some instances I use UserProperties to suppress notifications (example below for a text label).

To apply a programmatic change and allow me to suppress a notification I use this function:
void SetSuppressNotification(VoltageLabel label, String updatedValue) {
if (!label.GetText().equals(updatedValue)) {
label.SetUserProperty("SuppressNotification", 1);
label.SetText(updatedValue);
}
}

In notify I check if the notification is suppressed:
case Label_Changed: // The text of an editable text control has changed
{
if (component == delayTimeInput) {
if (!CheckSuppressNotification((VoltageLabel)component)) {
String tempString = (String)object;
int tempInt = Integer.parseInt(tempString);
SetDelayTime(tempInt, false, false);
}
}
}

The helper function here:
boolean CheckSuppressNotification(VoltageLabel label) {
boolean returnValue = false;

Object updateUIPropertyValue = label.GetUserProperty("SuppressNotification");
if (updateUIPropertyValue != null && (int)updateUIPropertyValue == 1) {
label.SetUserProperty("SuppressNotification", 0);
returnValue = true;
}

return returnValue;
}

Maybe not an answer to your question but might give you some ideas.

Would be great to get some feedback from Cherry Audio on this but they are not very active on this forum.

Regards
Tobias

[arbuxMusic]

Cherry Audio are normally really responsive to incidents through their support forum @ https://cherryaudio.kayako.com/. (You can get to this URL from https://cherryaudio.com/voltage-modular/support by clicking the Support tab at the top of that page)

I usually create a Voltage Module example and reproduction steps to show how to reproduce the problem for them, submitting through the kayako site. If it needs some user interaction help, I normally link a YouTube to show what the challenge is as well.

[flucatcher]

That's good, I only used it for problems with the store / publishing and always got quick and efficient help.

I still think it would be good to have a little bit more active forum, then more people could learn from the questions and answers.

[arbuxMusic]

100% agree.

[ColinP]

Hello again!

I started this but unfortunately my posts got accidentally deleted and apparently can't be brought back to life. So I'm just posting this to explain why this thread looks so confusing.

Hopefully tomorrow I'll post again reprising the missing info for anyone who has just found this and is thinking "What? This doesn't make much sense!".

Regards, Colin

[ColinP]

OK, I've done a bit more work on this so can present a solution that works for most cases, but first I'll repeat some of what I wrote in posts that got accidentally deleted by the moderator so that this makes sense to anyone who didn't see the original OP.

So the problem I began this thread to discuss is when your module contains both managed components like knobs and unmanaged components like digital counters. VM handles simple things like knobs for you so you don't have to worry about them much but unmanaged components that have an internal state need to be handled by your own code.

So when a change is made to an umanaged component you need to use CreateUndoNode() to handle undo/redo and you also need to add code to GetStateInformation() and SetStateInformation() so that your module's internal state can persist in presets and the default VM project that users are working on.

Now this all works fine until the user selects reset controls or randomise controls from the module's right click menu.

VM then automatically adds an Undo node to the undo/redo stack that handles any managed components but it has no means to store or restore the internal state for your unmanaged components. But if you add your own undo nodes on catching the Reset and Randomize notifications in Notify() then you end up with two nodes on the stack and a bit of a mess,

I think this could be fixed by a mod to VM so that it calls GetStateInformation() and SetStateInformation() from inside it's automatic reset and randomize module undo handling. But there is a simple workaround that uses invisible knobs to effectively turn unmanaged components into managed ones.

Many thanks to Captain for posting a while ago on using invisible knobs, I found his solution trawling through the old forum posts this morning. It's a slightly lateral ideas but works like a dream.

So basically all one does is use an invisible knob to store the state of say a digital counter and then VM manages all the undo, redo, resetting, randomizing and preset persitence functions for you automatically. It won't work for complex internal states but if your state is just a handful of parameters it does the job with far less coding AND gets around the double undo nodes on the stack problem.

The solution is pretty simple but as it's a general purpose thing I'll start a new thread called "How to use invisible knobs".