DestroyFcn callback of simulink block is ignored half the time.

I was observing unexpected behaviour on a program I am writing and discovered that the DestroyFcn callback is ignored half the time a block is deleted. DestroyFcn is supposed to be called after a block is graphically deleted, when the block is destroyed in the memory.

The block in quesiton is a masked subsystem in a reference model. When the block is used in a project, it's dragged from the referenced model to the project model.

I did the following investigation to identify DestroyFcn as the problem :

1. Put the following code in the reference block DestroyFcn callback (contextual menu -> properties -> callback -> DestroyFcn);

msgbox('destroy')

2. Drag the block in a project model named 'MODEL'. Name the block 'BLOCK';

3. Run the following code to get the block Handle;

get_param('TEST/BLOCK', 'Handle')

4. Delete the block, expected msgbox pop-up, but nothing happens;

5. Re run step 3 code to see if block is still loaded in memory, receive this message;

" Invalid Simulink object name: TEST/BLOCK.

Caused by:

No block called 'TEST/BLOCK' could be found. "

This confirms the block was deleted from memory, and the fact that no msgbox pop-up was received makes me belive that code in the callback was somehow ignored.

I also tried different lines of codes in step one such as "disp('destroy')" and different ways to test if the block is still loaded such as "getSimulinkBlockHandle".

Did anyone ever exepirenced this ? Is this a bug or am I ignorant ? I'm on 2020b.

Answer 1

[Wei Jiang]

Hi,

I understand that you find that DestroyFcn callback is not called when you delete a block in Simulink.

The issue might be that you delete the block graphically.

Based on Block Callbacks documentation, if you delete the block graphically, DeleteFcn callback will be triggered instead of DestroyFcn. To trigger DestroyFcn callback, you can try to delete block by 'delete_block' command or close the model.

One more thing to mention is that after deleting a block graphically, it is true that you can not get the block handle anymore. However, it does not mean that the block is destroyed from memory, e.g. you can undo the deletion and get the block back to model.

Thanks,

Wei

[P Lepage]

This helps a lot ! I was using DestroyFcn callback because I don't want to consider the deleted block in a find_system that is triggered by the callback.

Before DestroyFcn, I was using DeleteFcn. The callback triggers before graphical deletion, which is not bad, but the block ends up in find_systems and that is a problem.

Do you know of any way to prevent this ?

I'm a little suprised about your last point. I would have guessed that the undo features works by using a Command desing pattern complemented by a Memento, but I get that you guys have your reasons for implementing Matlab that way.

Thank you for your time,

P.L.

[Wei Jiang]

Hi P.L.,

It is an expected behavior that the block handle is still valid when DeleteFcn is called.

Unfortunately, we do not have a "PostDeleteFcn" callback at this time. You might have to modify your callback script manully to achieve your goal.

Thanks,

Wei