PR# 13123 Restoring toolbar layout after changing language crashes or goes into infinite loop

When the toolbar layout is restored and the language was changed, EiffelStudio goes into an infinite loop (when assertions are disabled) or a check-clause is violated (with assertions enabled) and only a partial address toolbar is loaded.

The problem occurs since the toolbar layout is saved using the names of the items. When the language changes, the items are not found anymore since the name changed. This violates a check clause {SD_TOOL_BAR_ZONE_ASSISTANT}.open_items_layout: tag "must_found". (see screenshot crash_loading_toolbar.png)

If the check is not evaluated, a Void element is inserted into the list of toolbar items. This will lead to an infinite recursion due to the retry clause in {EB_DEVELOPMENT_WINDOW}.restore_standard_tools_docking_layout. This feature calls `internal_construct_standard_layout_by_code' normally and after a retry, but in this feature the error occurs, thus the infinite retry loop. (see screenshot crash_loading_toolbar_infinite_retry.png)

For EiffelStudio to work again, the docking directory has to be deleted.

The items which are problematic are (at least) the class/feature/view label, the class/feature address box and the view buttons. These have names which are translated. Some items like the history back button have a hardcoded name in {EB_HISTORY_BACK_COMMAND}.name.

All toolbar items which have a name which gets translated are problematic and their internal name has to be made invariant to the interface language or the way the toolbar is saved/restored has to be changed.

The retry clause (or the action after the retry) has to be changed so that if something goes wrong (maybe other than the current bug), no infinite loop occurs anymore (only one retry of the same feature call to `internal_construct_standard_layout_by_code').

* Open EiffelStudio
* Change the toolbar layout, remove the "Class label" or "Class address" from the address bar.
* Change the language
* Restart EiffelStudio

This bug is fixed in revision#69176.

Thanks for your report.

Attachments for problem report #13123