Open dragonrider7225 opened 3 months ago
Thanks for the bug report.
Simplified, this illustrate the problem:
// Functional: This Ok button works
export component FunctionalDialog inherits Dialog {
StandardButton { kind: ok; }
}
// "Broken: This Ok button doesn't work
export component BrokenDialog inherits Dialog {
callback ok_clicked();
StandardButton { kind: ok; }
}
That's because we only create the alias if the magic callback doesn't exist.
This code is responsible to create a alias such as callback ok_clicked <=> ok-btn.clicked;
Because we use a or_insert_with
, we don't create it if it already exist.
We could create one if it did exist, but we need to be careful that the signature match.
Unfortunately, if we are to implement that now, that would break your workaround as this will then be an infinite recursive call.
I hadn't realized that callbacks could be aliases. Adding explicit aliases to the dialog definitions should be a better workaround than explicitly delegating the StandardButton
s' clicked()
callbacks to the root and setting the root's cancel handler in real_new()
.
But also, I'm not clear how making the StandardButton
s' associated callbacks unconditionally being aliases would break my workaround. With the current behavior, when I delegate the StandardButton
s' callbacks to the root, I also need to explicitly set the handler in Rust code for the callback that I'm delegating to, which would override the delegation to the root that could cause an infinite loop with the aliasing.
What I expected to happen
Explicitly declaring callbacks related to
StandardButton
s (so that I can refer to them elsewhere in the dialog, e.g., with aFocusScope
) does not break the buttons.What actually happens
A
StandardButton
ofok
kind only has an implicitclicked => { root.ok_clicked(); }
callback if theroot.ok_clicked()
callback is not explicitly declared in theDialog
.My minimal reproduction
Zipped