Delete the "end" that you manually entered from the callback function, it's superfluous because app designer builds the function prototype automatically including the function...end lines. Look at the stub in the sample app I posted earlier.
It seems as though the parser could catch this and be more informative; but when the second "end" was encountered, it closed the class definition too soon and that's where the code parser/analyzer broke. One might consider submitting an enhancement request that if the user enters an "end" in a stub callback function that would match up with the function of that callback, it be warned; whether that would be feasible or the cure worse than the disease, I don't know, just a thought.
The comment about the dangling "end" statement I made first was/is actually what the problem is; it shouldn't be there.
What it shows is that one should only add functional code inside the callback functions; App Designer builds the function code. It also illustrates a problem with MATLAB syntax in that "end" is used to close all structures from classes to functions to if and switch constructs, for loops, and whatever else I've left out. Consequently, it's not easy to determine what the given "end" relates to; that's why Walter suggested looking at the code indentation tool; it tries to match opening and closing constructs and helps find mismatches. The editor also will highlight the opening or closing of a construct; if you hover over that "end", you'll see it matches with the function, but then you also have to recognize that the function prototype was already built for you.
