Linked constraints don't work with spaces.

[rainharvester]

Attached is a simple file.
The height of the square is "GlobalHeight".
The width of the square is "GlobalHeight + 10mm"

Change the name of the height to "Global Height" (add a space). No error is given.
Click on the width. Click on the blue function circle. You will correctly see : Constraints.<<Global Height>> + 10mm
Click bottom-most "OK".
Click on the width again. Click on the blue function circle. You will see : Constraints.Global Height + 10mm (notice the "<< >>" is gone. Why?!)
(Bug#1)

Sometimes when you save the file (save-close-load-modify-height then repeat x2), this "Failed to parse expression isn't seen". Also, I didn't change the expression, the program did. It removed the "<< >>" to break the link.
(Bug#2)

Also, if the user originally uses a space in "Global Height", the program gives no indication that "<< >>" is necessary when adding the constraint, and even recommends the name "Constraints.Global Height" ( ie no "<< >>").
(Bug#3)

These bugs can get very confusing when many objects are linked and no error message are given (unless you click everything looking for an error). In the case of Bug#2, no error is ever given (the program silently modifies your files).
Can someone verify so I can submit this bug? Thanks.

[chrisb]

I think this has been discussed here before, perhaps there is already a tracker entry, but I don't know if it is really a bug.
I never have these issues because I never ever use names with spaces or non ascii characters, but I can understand that others use this.
However, there is no need to allow this in expressions as well. So an error message should be enough if spaces occur in expressions. The generic message "Failed to parse expression" might be too general.

[Jee-Bee]

In my opinion the only possible bug is that expressions accept spaces...
However the result would be that some users link to expressions that don't exist and complain about that...

One thing i have checked when you give a cell in libre office a name with spaces it don't accept it too. I didn't check but i'm quite sure that excel don't accept it too. python/ Matlab/ octave don't accept a space in a variable too. Sound almost like logic

I checked https://www.freecadweb.org/wiki/Expressions There is nothing said about no spaces, but all examples don't contain spaces also the expresion properties like CenterOfMass.
Last point i want to make... I'm quite sure even if there was written that an expression can't contain spaces. Almost nobody reads it.

[ezzieyguywuf]

there is no need to allow this in expressions as well.

In my opinion the only possible bug is that expressions accept spaces...

I am reviving this old thread due to the work I'm currently working on trying to make some small improvements to the Spreadsheet module. See here.

One of the bugs listed as associated with the Spreadsheet module is 3696.

As discussed in the bug report as well as in this thread, the real bug here is that spaces are ever allowed to be entered in the Gui for an "expression" (or what I refer to in this post a "Path").

Consider the following:

Code: Select all

import Part
doc = FreeCAD.newDocument("MyDoc")
feat = doc.addObject("Part::Box", "BoxName WithSpace"
print(feat.Name) # prints out "BoxName_WithSpace"

It seems that the Part workbench has elected to silently allow users to create objects with invalid names, but in the background replaces spaces with underscores.

This is actually quite counter-intuitive, as the tree display still shows the space rather than issuing an error, but I guess that's off-topic...

In short: should the ExpressionParser be updated to handle spaces more gracefully? Or is the <<Name With Space>> syntax sufficient?

If so, should we update the Gui elements (and indeed, the python api...) which accept spaces without error and throw an error, since the name is technically invalid without the double-bracket escape?

[vocx]

...
It seems that the Part workbench has elected to silently allow users to create objects with invalid names, but in the background replaces spaces with underscores.

This is actually quite counter-intuitive, as the tree display still shows the space rather than issuing an error, but I guess that's off-topic...

I don't know if this is done by Part, or by more core functionality, but yes, it seems to be a mechanism to get valid internal names of objects, which can only be alphanumeric, and the underscore.

(Bug?) FreeCAD changes a starting "0" (zero) into an underscore "_" in a file name.

In short: should the ExpressionParser be updated to handle spaces more gracefully? Or is the <<Name With Space>> syntax sufficient?

If so, should we update the Gui elements (and indeed, the python api...) which accept spaces without error and throw an error, since the name is technically invalid without the double-bracket escape?

The <<double signs>> syntax looks fine to me because it is somewhat intuitive (delimiters help establish the scope), but if you think it could be handled better then please let us know.

I think changing the invalid characters to underscore is not bad as long as this behavior is consistent and well documented. At least I wrote a note in Part_Feature (Scripting), which is the base class of most objects with a topological Shape.

[Jee-Bee]

I would say just same handle expressions the same as python AND excel does:

• Start with letters
• No spaces

and if typed wrong just raise an error

[chrisb]

I think changing the invalid characters to underscore is not bad as long as this behavior is consistent and well documented. At least I wrote a note in Part_Feature (Scripting), which is the base class of most objects with a topological Shape.

This is an issue if the same name is used with underscore and space. It seems to the user to be different, bit internally it isn't.
I'm not a friend of automatisms, which try to be smarter than the user. In many cases it is possible, but in corner cases things become very obscure and cumbersome.

Forbidding spaces in expressions is an extremely clear rule which is easy to understand and easy to follow. Allowing spaces seems to be intriguing, but the need to mask them makes the expressions much more difficult to read than having a name without spaces.

[chrisb]

While you are working on Expressions - and many thanks for that! - it would be great if autocompletion could be improved to the state before the expressions extension. See https://forum.freecadweb.org/viewtopic. ... 07#p331207 .

There were already several topics asking for it.

[ezzieyguywuf]

I think changing the invalid characters to underscore is not bad as long as this behavior is consistent and well documented

This is an issue if the same name is used with underscore and space. It seems to the user to be different, bit internally it isn't.
I'm not a friend of automatisms, which try to be smarter than the user. In many cases it is possible, but in corner cases things become very obscure and cumbersome.

I'm with chrisb on this one, I don't think it's wise to hold the users' hands in this regards. If they do something wrong they should be told about it and not allowed to move on.

Forbidding spaces in expressions is an extremely clear rule which is easy to understand and easy to follow. Allowing spaces seems to be intriguing, but the need to mask them makes the expressions much more difficult to read than having a name without spaces.

+1 I agree with this.

While you are working on Expressions

I'm supposed to be working on the Spreadsheet module. But as I'm finding out, the Spreadsheet module in and of itself is pretty robust, it's the ExpressionParser that seems to be causing the issues/"bugs" that are being reported as "spreadsheet module" bugs.

...so maybe I am working on Expressions

[vocx]

...
I'm with chrisb on this one, I don't think it's wise to hold the users' hands in this regards. If they do something wrong they should be told about it and not allowed to move on.

Okay, then you have my support as well. Let's void spaces in expressions. Unfortunately, a lot of Windows users are used to write spaces in file names, directory names, etc., so they need to learn the Linux way, which is using underscores.

...so maybe I am working on Expressions

LOL. You are!