FR: UndoManager


#1

undo

I’m implementing an undo/redo selector á la Visual studio, but I’m missing three vital functions in UndoManager. Would it be possible to have these added?

const String& getTransactionName(int index) { return transactions[index]->name; }
int getDepth() const  { return nextIndex; }
int getNumTransactions() const { return transactions.size(); }

#2

I’m happy to add some methods to access this stuff, but all these suggested methods are confusing… what is “depth” supposed to be? What’s the index relative to? Is it talking about undos or redos, or both? Is “num transactions” the total number of both undos and redos?? If you can give a better set of methods that do what you need and which are also a bit more understandable, I’m sure they can be added!


#3

Sorry, I just forwarded the names I used myself. Naming variable/function-names is a hard thing, I reacently read somewhere…

Anyway, I gave you the function bodies so you can see yourselves what they are doing…i.e you can paste the functions right into the undomanager code and they will work. index, nextIndex, transactions are your own varable names.

I guess you can call getDepth() getCurrentTransaction() or something alike instead, I guess I was thinking of depth into the transaction stack…

getNumTransactions() and getTransactionName() should be pretty obvious I think, and be consistent with Juce naming conventions, but you can of course give them whatever names suits you, I’m not picky… :slight_smile:


#4

What about just

StringArray getUndoDescriptions() const;
StringArray getRedoDescriptions() const;

?


#5

…i.e. the number of items in the list tells you how many in either direction


#6

That’s what I did in my implementation… but I just use a single StringArray and the undo index points to the Description index (but I wrote my own UndoManager from scratch).

Rail


#7

As long as the division between the two array is correct I guess it will do. It means fewer number of function calls for the client but extra job in the undomanager to prepare the StringArrays, don’t what consumes less cpu cycles…

As for the getDepth() aka numberOfAvailable undoes, I think it’s a useful indication of the number of stored undoes even if you don’t implement my undo/redo combos.
This is what I do

void showPopup() override
{
	clear(NotificationType::dontSendNotification);

	auto currentUndo = undoManager.getDepth();

	if (isRedoCombo)
	{
		auto numTransactions = undoManager.getNumTransactions();

		for (auto i = currentUndo; i < numTransactions; i++)
			addItem(undoManager.getTransactionName(i), i + 1);
	}
	else
	{
		for (auto i = currentUndo; --i >= 0;)
			addItem(undoManager.getTransactionName(i), i + 1);
	}

	setText(getItemText(0) + " ", NotificationType::dontSendNotification);

	ComboBox::showPopup();
}

#8

OK, will push this shortly.


#9

Any news regarding this feature? I’m on the latest development branch and can’t find it.


#10

Look for

UndoManager::getUndoDescriptions()
and
UndoManager::getRedoDescriptions()


#11

Just realizied I forgot to update my local doxygen. Thanks!