Bug #5750: Failed to parse expression occurs when referencing an alias in an external spreadsheet document

[Kunda1]

issue #3272: Failed to parse expression occurs when referencing an alias in an external spreadsheet document

Description

By "external" I mean a spreadsheet that is not a part of the FreeCAD document I am working on. I am choosing to use a separate master spreadsheet because I want that central spreadsheet to control dimensions in constraints used in sketches in multiple FreeCAD documents in the current working directory, such that when I update the values in the "master spreadsheet", the objects in the dependent FreeCAD documents are updated (well, right now they are not updated automatically, and I have to press a button in Assembly2, but that is off-topic from this bug).

After working around the bug feature in issue #3271 by manually opening the external spreadsheet file, the fx button does seem to show that it recognizes the syntax and even shows the value, but when I click ok to use that value, I get a "Failed to parse expression" error.

Use the same attachments as in issue #0003271

The GIF in issue #0003271 also shows this problem.

Steps To Reproduce

Extract the tarball.
cd into the directory that is extracted so that the current working directory can resolve paths to other files in the set of files.
Open up the file: freecad-daily UpsideDownMonitorMount.fcstd
Open up the Leg.fcstd file using the button.
Open up the MasterSpreadshet.fcstd to work around the bug in 0003271
Double click on the sketcher
Double click on the constraint with 1.5yd ("Shelf Depth")
Click on the fx button.
Type in a reference to the alias that is in the spreadsheet: MasterSpreadsheet#Spreadsheet.Sd
Notice it says Result: 12.00 " which is correct: the spreadsheet has 12in in the Sd alias
Click Ok
Notice the Length field also shows 12.00 " which is correct so far.
Click Ok
Now see a popup error with window title "Dimensional constraint" and "Failed to parse expression". There is also "Failed to parse expression" in the Report view.

OS: Ubuntu 17.04
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.12643 (Git)
Build type: None
Branch: master
Hash: 868d9cc6c215ce3a2ab20d454378ec00e1b9ed26
Python version: 2.7.13
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: English/UnitedStates (en_US)

[bgoodr]

The part of this that I consider a bug is that the tool's messaging is cryptic. It does not remind the user that they need to open up such and such external file. The syntax of the thing being referred to should be sufficient for the tool to popup a dialog saying "Would you like to open up <some_spreadsheet> to resolve this reference? [Y/N]".

[ezzieyguywuf]

ping

@bgoodr (or anyone) - can you provided a step-by-step on how to reproduce the issue from "scratch"? I can confirm the error using the provided tarball, however I've attempted a few times to set up the same scenario and can't reproduce the error.

Edit:

Attached are the files I've created trying to duplicate the error. "PartWB.fcstd" references "MasterSheet.fcstd"

[ezzieyguywuf]

I have found the steps necessary to reproduce the error - it seems that this is somehow connected to using a named constraint.

In other words, the following results in no error

1. Create new document
2. switch to Spreadsheet workbench
3. Save document and give it a name, i.e. "MasterSpreadsheet.fcstd"
4. create new spreadsheet
5. enter value, right-click, give it an alias
6. Create new document
7. Switch to Part Design workbench
8. Create new sketch
9. Create rectangle
10. Add length constraint to any side
11. Click "fx" button
12. Use auto-complete feature to reference previously created spreadsheet, including filename, e.g. "MasterSpreadsheet#Spreadsheet.MyAlias"

If we slightly modify this procedure, we can duplicate the error:

1. Create new document
2. switch to Spreadsheet workbench
3. Save document and give it a name, i.e. "MasterSpreadsheet.fcstd"
4. create new spreadsheet
5. enter value, right-click, give it an alias
6. Create new document
7. Switch to Part Design workbench
8. Create new sketch
9. Create rectangle
10. Add length constraint to any side
11. Add name to length constraint, e.g. "My Length". Notice the space - this is necessary in order to reproduce the issue
12. Click "fx" button
13. Use auto-complete feature to reference previously created spreadsheet, including filename, e.g. "MasterSpreadsheet#Spreadsheet.MyAlias"
14. Click "OK" to finish defining the length constraint - NO ERROR
15. Re-open the same constraint (double-click) in order to edit it
16. Without changing anything, click "OK" to finish defining the length constraint - ERROR

This gives a nice clue as to which direction I must search to try and resolve this issue.

It also reinforces the effectiveness of clear, step-by-step directions to reproduce issues in bug reports.

I should note that simply deleting the name of the constraint does not solve the problem - rather, the entire constraint must be deleted and recreated, without ever giving it a name.

Update:

hm... it seems "hint" was definitely the appropriate word here. While I can effectively turn the problem "on/off" using the tarball provided in bug 3271, I'm still having intermittent success doing so on a "from scratch" document that I've created myself. I think spending some more time reliably recreating the issue will help to uncover what may be going on...

Update2:

It seems the key here is to have a space in the name of the constraint. I've updated the step-by-step above to reflect this. Further, it seems that the first time the parser attempts to resolve the path, it doesn't have any issue. It only struggles whenever it tries to re-solve it. This is also reflected in the step-by-step above.

Update3:

After more tinkering, I'm almost 100% sure that the issue is caused by spaces in the constraint name. I can now effectively turn the problem "on/off" using either the tarball or my own document. I can even do so without deleting the constraint

To turn "ON"

1. Edit any existing constraint that references an spreadsheet
2. add a space to the constraint name
3. Click "OK" to close the constraint
4. open the constraint back up
5. click "ok" again to observ the error

To turn "OFF"

1. Edit any existing constraint that references an spreadsheet and has a constraint name with a space in it
2. Click the "fx" button and click "clear" to delete the link to the spreadsheet
3. Click delete the space from the constraint name
4. Click "ok" to finalize the constraint - note, there should now be zero spaces in the constraint name and the constraint value should _not_ be greyed out, indicating it is not referencing a spreadsheet.
5. open the constraint back up
6. Click the "fx" button
7. Type in a reference to any spreadsheet
8. click "ok" twice (once for the "fx" dialogue, once for the constraint dialogue) and notice there is no error now.

[bgoodr]

It also reinforces the effectiveness of clear, step-by-step directions to reproduce issues in bug reports.

I was wanting to answer your original question, however you beat me to the punch. But you ended up with a much better description of the steps to reproduce the original problem then I could have anyhow.

I think my original posting that used tarballs is less effective than describing the problem from scratch as you did. Duly noted for future postings.

[ezzieyguywuf]

I think my original posting that used tarballs is less effective than describing the problem from scratch as you did.

Yes I agree with this.

Duly noted for future postings.

Awesome! That’s exactly the type of response I was hoping my comment would elicit.

[Kunda1]

Bumping

Also ticket has been migrated to github: issue #5750