Problems with backward compatibility

The attached file works in MATLAB through 2014a. Now the MATLAB program is no longer compatible with this file. How can a software package not be backward compatible? More to the point, does anyone have a fix (or fixes) for the attached file? Thank you for your time.

[John D'Errico]

Oh, come on. Be serious. Things change. But do you expect someone to go through every line of hundreds of lines of barely commented code for you, finding any possible problem, without even knowing what the code does? And of course, do this service that might take multiple hours to do, out of the goodness of our hearts?

If it suddenly stopped working, read the release notes for the last release when it stoped working. You will find a list of things that changed in that release. There will have been good reasons for what was done.

[Robert Wolverton]

I agree that this code is not well written. This file is similar to pplane.m and dfield.m, i.e. written a decade ago in a galaxy far, far away. And I do not expect any goodness from your heart, John, but thanks for reading and responding.

Answer 1

[Jan]

 How can a software package not be backward compatible?

The answer for this question is trivial: If the language changes, the code can contain incompatibilities. Matlab has changed since R2014a.

I'm sure you have any information about the incompatibilities, perhaps error messages or a modified behavior e.g. a different result. If you want others to help you to fix your code, it would be kind if you provide these information instead of letting the readers repeat the work of identifying the problems.

Hints:

• You define callbacks using strings - this is outdated since Matlab 6.5, for over 15 years now. Use function handles instead.
• Use groot instead of "0" to address the root object.
• You get many many many warnings in the editor for your code and a lot of suggestions how to fix them. It would not be useful, if I repeat all of them, when you can see it directly in your editor already.
• Please fix the problems by your own already. It is unlikely that the voluntary members of the forum debug a code with 1429 lines, when the author does not show any own effort.

[Robert Wolverton]

Jan, thanks for looking at the file. I am not the author and do not have the knowledge and skill to untangle the errors. I've tried for hours to work through the functional controls, but my MATLAB knowledge is limited to basic programming.

Answer 2

[Walter Roberson]

The code was not correct in previous versions either. It attempts to store and retrieve 'user' information for sh(1) (also known as frame(1)) without ever having initialized that location. The code initializes

frame(2) = uicontrol(.....)

which creates one uicontrol and stores it in the second location of frame, leaving the first value unresolved.

The code took a lot of advantage of the fact that graphics objects happened to be represented as double values, and mixed together graphics handles and numeric values in the same array. Although that was technically possible before, it was never a good idea.

The code pushes data into and out of 'user' using the same vector variable name, sh, but it turns out that you have two different vector formats:

frame (length 2), wind (length 9), butt (length 3), Matrix (length 4), Matrix (length 4), Object (length 1), settings (length 6)

and

 % dh(1)      nframe
 % dh(2:3)    notice
 % dh(4:7)    butt
 % dh(8)     menu
 % dh(9)     ddispa
 % dh(10:13)    Matrix
 % dh(14:17)     Martix
 % dh(18)    Object
 % dh(19)    Color
 % dh(20:21)    Vector 
 % dh(22)    Rescale
 % dh(23)    ax
 % dh(24)    colo = color

Since you use the same variable "sh" to refer to both of those, that is asking for problems in accidentally indexing the wrong item.

[Walter Roberson]

I made a lot of text edits to the code to try to make it work. Unfortunately it turns out to refer to compass2() which is not defined and not part of MATLAB and not present in the File Exchange.

Updated code enclosed. I am virtually certain there are some remaining problems but I cannot test through without compass2.

I mentioned above that you have two similar but incompatible setups of vectors of values stored in user data. I found a location in the code where you set(gcf, 'user', sh) and then a few lines later dh = get(gcf, 'user') thus storing vector in sh arrangment and then retrieving it as if it were in dh arrangement. I think that is something that the author of the program is going to need to fix.

[Walter Roberson]

Code with more fixes attached.

Answer 3

[Robert Wolverton]

Thanks Walter. I really appreciate your time with this. I'll see if I can find the compass2() function.

[Robert Wolverton]

compass2.m appears to be a modification to a built-in MATLAB function. I found a copy - attached.

[Walter Roberson]

Also polar2()

I did find a couple of typing mistakes in what I did before, but it needs more testing yet.

Answer 4

[Robert Wolverton]

Thanks again Walter. I have attached the file.