I had no problems to change the label of "rrpm" and "krrpm"from "Variable" to "Unit" via the menu.
But I remember that from time to time in the past I had a similar problem as the one you describe - changing the label via the menu did not work as the label would immediately snap back to "Variable" as soon as the focus was out of the region.
I don't know what caused that misbehavior.
But changing the label using the keyboard shortcuts always worked OK.
You can use Ctrl+Q to cycle through the seven label-types or you can use Ctrl+U to toggle between "Unit" and "Variable".
According Prime processing disabled regions: No, I don't think that disabled regions are processed to any degree. When you disable a region you still see the state the region was before disabling it.
So if you have a second global definition of the same variable or unit (which Prime no longer allows, unlike real Mathcad) is gets red bordered and when you disable the region the red border persists. I would call it a buggy behaviour or at least something undesirable.
Its similar to evaluating a variable
and after disabling the evaluating region it would still show the former result
I think it would make more sense if all calculation results and error indicators would be deleted when a region is disabled.
On the other hand 'freezing' a result to compare it with a calculation done with changed input values might make sense in some cases, but there sure are other options as to achieve a similar effect.
According persistent error indicator I noticed an even worse effect in 2D plots. A red error border around a plot region would not go away even though the problem causing it was already fixed. A recalc did not solve the problem, saving, closing the sheet and reloading it did. A more convenient solution was to cut and then paste the plot region.
@krs wrote:
updated file.
The weird thing is that when I reopened this doc I still saw the stuck label (stuck as variable) and several of you had no problem with this document. So it isn't the file itself??? Does that point to some system issue?
Not exactly sure what you mean!?
When I opened the first file you posted I saw that "rrpm" was labeled as "Variable" and so using it as unit when evaluating the 10 Hz failed.
I understood that you were not able to permanently set the label when you define the unit and I remembered that I has the same problem sometimes in the past. I can't say what causes that erroneous effect and why it was going away.
But the file you posted now seems to be perfectly OK.
The error seen in the left picture you embedded in the file stems from the fact that of course you can't use a variable (or unit) defined the "normal" way ( with ":=" ) in a global definition. This is expected behaviour (and also was so in real MC15).
According the documentation of the keyboard shortcuts Ctrl+Q and Ctrl+U. They might(!?) be documented somewhere in the help but when you are looking for that kind of information, Prime's help sure is ... demanding, to say the least.
I'm not sure how and where I discovered these keyboard shortcuts.
Maybe it was just through trial and error—the same way I found the window that lets you change a few colors and other settings.
Namely, with Shift+Ctrl+Alt+Q, which is probably not documented anywhere—use at your own risk 🙂
BTW, even though it possibly has nothing to do with your problem of not being able to set the label vie the menu, I agree with Stuart that its a good idea to avoid global definitions whenever possible. This was a good advice already for old Mathcad and still applies to Prime.
Hi Werner, could you clarify please? something may have clicked in my head
Do you mean that anything with a global-equal assignment must be intrinsically defined? i.e. no dependencies on other variables?
@krs wrote:
Hi Werner, could you clarify please? something may have clicked in my head
Do you mean that anything with a global-equal assignment must be intrinsically defined? i.e. no dependencies on other variables?
When precessing the worksheet in a first pass only the global definitions are parsed. So when a global definition uses a 'normal' one, it has not yet been processed and is therefore unknown.
A globally defined variable (or better: constant, as it cannot be altered in Prime other than via the API) can depend on others, but these must be defines globally as well (and above it). In fact you did exactly that when you (globally) defined the unit krrpm based on the (globally) defined unit rrpm.
On the other hand a normally assigned variable can use any globally defined one, no matter if its defined above or below it.
The new Maths Label sticks for me.
However, I notice that you're using Global Definitions. The behaviour of these is markedly different from M15. You can only define a name *once* using a global define. Unless you have a pressing and unique need to use a global definition, I'd suggest you use the colon-equals definition.
Stuart
