Resuming from "keyboard" command?

I'm using the "keyboard" command to stop the execution in a nested (callback) function (which is triggered by a pushbutton) in order to make the user able to modify its workspace.

function myFunc()
...
    function myNestedFunc(h,~)
        load('myMatFile.mat','myGraph');
        openvar myGraph.Edges;
        keyboard;
    end
end

The problem is, that to exit from the debug mode, the user should run "dbcont" in the Command Window. But I want to resume as soon as he finished to edit the variable.

If I try to write another callback function like this:

function myFunc()
...
    function resume(h,~)
        dbcont;
    end
end

I get the error "Debug commands only allowed when stopped in debug mode".

Is there a way to resume from "keyboard" without forcing the user to manually enter "dbcont" in the Command Window?

[Daniel M]

You can use the eval function along with timer objects to both check the value of a variable, as well as invoke dbcont. I'm on mobile right now, so can't provide a more thorough example/explanation, but hopefully this will get you started.

[Giuseppe Antonio]

If I use the eval function, I get the error "Debug commands only allowed when stopped in debug mode". I don't know if this depends on the MATLAB versions, but I must use it.

Any suggestions on how to overcome this problem?

[Jan]

@Giuseppe Antonio: Please open a new thread for a new question. Show the relevant part of the code and a copy of the complete error message.

Combining eval with debugging sounds like a wierd program design. I'm not surprised that such programming constructs are fragile. Do not use such crutches for productive code.

Answer 1

[Jan]

Using debug commands for an interaction with the user is a really bad design. A dynamic modification of the workspace is very fragile.

Resuming the debug mode througth another callback is strange also. Actually you should be able to check, if Matlab is in debug mode currently, but starting another callback while stopped in debug mode in another one, is at least confusing. Even including the dbcont in a try/catch block is not a smart solution - but worth to try for reasons of experiences.

Create a clean GUI for user interactions. Use the debugging methods only for debugging.

[Robert Scott]

This is not a solution. To simply say, go rewrite your program is as bad of a solution as the code design.

I can tell you i have the same issue as the OP. I have a program that the user needs to be able to access the workspace to open and close figures while the program is still running. Since the pause command in matlab does not work as per the documentation, the keyboard function is the only option and progrmattically returning from the "keyboard" command is the only way to solve the issue.

[Jan]

@Robert Scott: I disagree. Using keyboard to stop the processing and letting the interactively open and close figures, sounds like an extremely fragile programming style. If you get some final values, it is impossible to reproduce them reliably. Therefore this style of using the debugger as GUI is not a method I would use for serious scientific work.

I've seen many young scientists working with such methods, e.g. by calling a bunch of Fortran executables in a specific order, which changes according to the values. If they publish a paper based on values obtained in this way, you can be sure that they cannot reproduce their outcomes in the required period of 10 years. For software e.g. for clinical decision making, using the debug console interactively is not an option also: You cannot tell the legal department of the clinic, that you have to stop the program, type "x=5" manually, produce some digrams after some other modifications and declare the output as cause to perform a surgical operation.

Programming is more than writing code which creates some final values. Software engineering is an important part and suggesting a re-factoring is important and valuable.

"the keyboard function is the only option and progrmattically returning from the "keyboard" command is the only way to solve the issue." - No, the reliable way is to avoid to getting in such issues:

• Care for a clean and clear program design
• Use GUIs for user interactions
• If results must be reproducible, either document each setting of the GUI, or use the GUI to create a list of instructions, which trigger the actual calculations and which can be stored together with the data.
• If your program is useful, it should be usable to produce a paper or PhD thesis, and than stability and reproducibility are essential. Otherwise serious journals can treat your publication as fraud, if you cannot prove, that it is not.
• If your program is not useful, e.g. a short hack, do what you want with it and any programming style is okay.

Especially here in the forum it is important to teach reliable programming techniques.

[Robert Scott]

You are not "teaching" and this is why your comments are not solutions. Your comments are criticisms about programming style. Although i agree its important to push sound programming design choices, your comments continue to be non-sensical and off topic. There is no alternative method suggested. Just simply your comments as to why you shouldnt do what the OP was wanting to do. That is not an "answer" or a solution.

You are claiming above allowing a user to look at data during the interactive use of a multipurpose program that does many things renders the program poor. Have you ever used windows? Can you open a jpeg but still click on the start menu at the same time? yes, you can indeed! That is what im discussing here.

Programs that are user interactive and complete a task and then ask the user what "they would like to do next" are not poor programs. While the program is waiting for the user to select from a menu what they want to do next albeit while the user may want to open and look at a recently created figure from the programs previous task is not blasphamy like you would suggest. In fact its very normal.

Lets discuss solutions.

[Steven Lord]

I think you've opened a separate question for your specific use case, correct? In that case let's continue the discussion of that use case in that question rather than here, to avoid potential duplication of information and effort.

[Jan]

@Robert Scott: "There is no alternative method suggested." - Surely I've suggested to create a clean, stable and user-friendly GUI. I do not suggest methods, with which the programmer drills a hole in his own knee, and in the knees of the users of the code. If you really want this, post your own solution. You cannot claim, that I write, what you want to hear.