Disable custom Toolstrip based on conditions, which could be validated in sl_customization function

11 vues (au cours des 30 derniers jours)
Hi,
I'm developing a custom Toolbox, which supplies also a custom Toolstrip in Simulink.
I want to add functionality to disable this toolstrip, if some conditions are not met.
E.g. the Toolbox provides infrastructure to extend Requirements Toolbox, and it makes no sense, if user didn't install yet the Requirements Toolbox, or he doesn't have the license activated.
Documentation refers only to possibility to disable particular actions on the toolstrip, which i can register in the sl_customization function, but not to hide/disable toolstrip completely.
Any hint?
Thank you!
Best regards,
Nick
  2 commentaires
dpb
dpb il y a environ 3 heures
Never messed with them and don't have Simulink but couldn't/wouldn't your code be able to simply not create the pertinent toolstrip features if not pertinent? Or, if there are subsets, create those as tabbed, maybe?
Nick
Nick il y a environ 12 heures
Thanks, @dpb, for your comment!
Well, my understanding of the documentation for the Toolstrips, is that those are defined declaratively (you have to include couple .json files with definition of the toolstrip layout and the associated texts/icons/callbacks). And there are couple helper functions, which allow generating those json in development time. I didn't find any documentation on possibility to dynamically create Toolstrips or add controls to existng ones.
The only customization available for the toolstrips, is regstering "filter" callback for particular actions in toolstrip or context menu (https://ch.mathworks.com/help/simulink/ug/registering-customizations.html). Unfortunately, even in the callbackInfo of the filter function, there is nothing usable (at least directly) - there are some IDs of Studio object, etc.

Connectez-vous pour commenter.

Réponse acceptée

Nick
Nick il y a environ 7 heures
I found following workaround:
There is a command
slDestroyToolstripComponent("ToolstripName", Unregister=false)
which physically removes the Toolstrip configuration files from the file system, but (because of the 'Unregister = false'), leaves parent folder in the MATLAB Path.
So, I implemented a class, which copies reserve copy of the Toolstrip config files from other location, so I can trigger install/uninstall toolstrip by simple file manipulation:
classdef Toolstrip
methods(Static)
function install()
source = 'Folder with the Toolstrip configuration copy';
target = 'Folder, where the Toolstrip configurations are expected';
[status, msg] = copyfile(source, target);
if ~status
disp(msg);
end
slReloadToolstripConfig;
slReloadToolstripConfig; % The double reloading as workaround for missing icons on the first reload
end
function uninstall()
slDestroyToolstripComponent("ToolstripName", Unregister=false);
end
end
end
About the double 'slReloadToolstripConfig' command: if I use a single one - the Toolstrip is immediately appearing for already opened Simulink models, but the icons are not loaded. With double call - everything seems to be ok. It's likely an timing issue, as instead of repeating the same call, I can also use 'sl_refresh_customizations', which also would trigger reload of the icons. I guess, the first one is cheaper, though.
As an extension of this approach, I can implement e.g. replacing the Toolstrip actions with something else, if e.g. I want to give user a chance to see the toolstrip, but with some messages about missing prerequisites, etc. So, a bit of the "dynamic" appearance of the toolstrip (for all Simulink models, though).

Plus de réponses (0)

Catégories

En savoir plus sur Simulink dans Help Center et File Exchange

Produits


Version

R2025a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by