Does anybody know if there is a documentation of the error function telling why some strings lead to strange behaviour?
The effect can be confirmed not only in MC15 but back in Mathcad 11, too - the errormessages are slightly different, though.
Its annyoing - ever so often I am not allowed to add pictures to the post. The insert image window would open but never completes showing its full contenet - no buttons, etc.
So I only attach the files and maybe I am able to edit that post later adding a pic.
Now inserting the image seemed to have worked.
BTW, ever so often I see "currently being moderated" flashing at the upper left of my messages. Anybody any information about the moderation done here? I ever so often reply to a thread and after I sent my post I see some other answers which, according to the time stamp, should have been there when I first looked at the thread but they weren't. Time delay as of moderation?
Werner Exinger wrote:
Does anybody know if there is a documentation of the error function telling why some strings lead to strange behaviour?
The effect can be confirmed not only in MC15 but back in Mathcad 11, too - the errormessages are slightly different, though.
I have to admit I have never seen that before, but has to go down a fundamental bug. Have you reported it?
I corrected your document (added "\n" to end of string). And here is procedure for "error()" built-in function:
But why has this worked?
I suspect it's because of an exact match to certain internal short-names linked to the tool tips, so that the user gets to pick up the internal error message support.
I'm not sure where Vladimir picked up the code sample from, and hence which language facilities it's using (much of mathcad uses on the fly evaluation, so can determine the common err-string name issue I suspect is the rooot cause.
--Edit--
Have a look at the developers reference manual (on the Help menu, 3rd item :V15), and then look for the descriptions about "CreateUserErrorMessageTable" and "Creating Mathcad-Readable Function Libraries" - What isn't covered (as far as I can see) is how the tool-tips are generated which, as you see, can be different from the error strings.
As you can see there, the error messages are referenced by number, and there are functions to add new messages. So I suspect, as above, that duplicates are avoided, so you get the prior entry's results, and tool tips (which can't be set via those functions).
The error() function has three parts:
Try typing 1/0= to see the first two in action for an internal error. The problem is then finding their short string variants (e.g. those you have discovered). I suspect that with internationalisation (i18n) and localisation (l10n) that the strings are now another layer of dereference, so even further disconnected.
Philip
Cheers for the explanation Philip
VladimirN. wrote:
I corrected your document (added "\n" to end of string).
No, you simply applied a workaround. The bug occurs only if the strings are the exact ones I provided, as those messages seems to coincide with some internal error messages. Only the slightes minor change makes it work OK. So you may just prepend a blank or add an excamation mark to "correct" it 😉
And here is procedure for "error()" built-in function:
Yes - anything you'd like to tell us with this?
Furthermore thats muPAD code, not in any way the implementation of the error routine itself. It just tells the symbolics the interface. It can be found in the file basefuncs.mu which is located in ...\Mathcad 15\mupad\lib\basefuncs.mu. In another file mcad_error is mapped to mc_error.
Anyway, its a bug and interestingly enough it wasn't detected for very long time. At least it was already present in Mathcad 11. I was just curious if anybody already encountered it or knows something about it.
To answer Mikes question - no, I haven't reported that bug and most likely won't bother doing so.