How do I prevent resuming after a callback function interruption?

Hello,

I am coding the card game ERS. When I interrupt the computations under one keypress with another keypress, I would like the code not to return to the original computations it was performing initially. I have tried this implementation, but I was unsuccessful.

function UIFigureKeyPress(app, event)
            key = event.Key;
            switch key
                case 'space' % Slap key
                    ...
                return
                case 'p' % Place key
                    ...
                return
            end
        end

Answer 1

[Walter Roberson]

To prevent the previous computation from resuming, you have two choices:

1. Force infinite recursion so that you get an error
2. force MATLAB to quit

Depending on exactly what has been done, sometimes it is enough to force more memory to be allocated than your system can handle (including by paging to disk) -- but I recently found that can be caught (not sure it was something you could catch in all earlier versions.)

With R2021b, if the computation to be quit is running in a BackgroundPool, then you can cancel the operation.

In other words, for all practical purposes, you do not force the code to not return to the previous computations. Instead you set a state variable that the previous computation is responsible for checking to decide that it should quit itself -- rather than you forcing it to quit.

[Therese Demesa]

I see. Thank you! And for further clarification if you don't mind, if the original function was using public properties that were manipulated by the interrupting callback function, would it begin to use those modified properties or the properties it was originally working with? I am trying to setup those kinds of conditionals, but I'm stumbling across new errors with certain arrays and their indices.

[Walter Roberson]

If you modify the properties of a handle object, then all references to the handle object get the new values immediately.

If you modify the properties of a value object (not derived from handle class) then you are changing a local copy only.

A = do_some_class_stuff_non_handle_class;
B = A;
A.modify_some_property();    %does NOT change B

Not only does the above not change B: it does not even change A (unless you use assignin() to force it to change). You would need

A = do_some_class_stuff_non_handle_class;
B = A;
A = A.modify_some_property();    %does NOT change B

in order to save the updated A, because the version you modified inside the modify_some_property method does not affect the original object passed in -- not unless you use handle classes.