View Issue Details

IDProjectCategoryView StatusLast Update
0002770PathBugpublic2019-07-29 15:07
Reportermlampert Assigned Tomlampert  
Status closedResolutionfixed 
Product Version0.17 
Target Version0.17Fixed in Version0.17 
Summary0002770: Profile names wrong on startup
DescriptionWhen a file is saved with a Profile the names of the profile are not correctly displayed when the file is loaded back into FC. If a contour's name is "Contour :TC" what is displayed upon startup is ":TC".

Only after the first "App.ActiveDocument.recompute()" are the names correct - and functions using object's name work properly again.
Steps To ReproduceCreate part with PathJob and Profile around it.
Save file and close FC.
Start FC and load saved file
Additional InformationThe problem I noticed is that the original contour path does not get hidden when it is dressed up right after loading. The user has to manually hide contour. Once the name is correctly displayed, creating a dressup will also correctly hide the "claimed" contour path.
TagsNo tags attached.
FreeCAD Information



2016-12-10 23:32


path1.png (5,611 bytes)   
path1.png (5,611 bytes)   


2016-12-10 23:32


path2.png (5,829 bytes)   
path2.png (5,829 bytes)   


2016-12-10 23:39

developer   ~0007513

While working on the holding tags dressup the results of the missing recompute() became rather drastic (see attached screenshots).

Comparing the Path.Command's that get generated and the Path.Command's after the file is loaded back into FC shows that the serialisation and de-serialisation of float values might be the root cause.

Command G2 [ I:2.5 J:0 K:0 X:-2.641e-16 Y:12.5 Z:1.5 ]

After re-load:
Command G2 [ E:-16 I:2.5 J:0 K:0 X:-2.641 Y:12.5 Z:1.5 ]

It seems the exponent of X becomes a new key in the parameter dictionary "E:-16".


2016-12-10 23:47

developer   ~0007514

Extracting the fcstd file and checking it looks like serialisation is good:

G2 I2.5 J0 K0 X-2.6410315235593498e-16 Y12.5 Z1.5


2016-12-11 02:26

developer   ~0007515

Upon further investigation it turns out that according to the g-code specification exponent notation is not supported (which means the serialization code is what's wrong):


The following rules are used for (explicit) numbers. In these rules a digit is a single character between 0 and 9.

    A number consists of (1) an optional plus or minus sign, followed by (2) zero to many digits, followed, possibly, by (3) one decimal point, followed by (4) zero to many digits - provided that there is at least one digit somewhere in the number.

    There are two kinds of numbers: integers and decimals. An integer does not have a decimal point in it; a decimal does.

    Numbers may have any number of digits, subject to the limitation on line length. Only about seventeen significant figures will be retained, however (enough for all known applications).

    A non-zero number with no sign as the first character is assumed to be positive.

Notice that initial (before the decimal point and the first non-zero digit) and trailing (after the decimal point and the last non-zero digit) zeros are allowed but not required. A number written with initial or trailing zeros will have the same value when it is read as if the extra zeros were not there.

Numbers used for specific purposes in RS274/NGC are often restricted to some finite set of values or some to some range of values. In many uses, decimal numbers must be close to integers; this includes the values of indexes (for parameters and carousel slot numbers, for example), M codes, and G codes multiplied by ten. A decimal number which is supposed be close to an integer is considered close enough if it is within 0.0001 of an integer.


2016-12-11 03:15

developer   ~0007516

As it turns out fixing the serialisation does not fix the recompute() issue. Back to the drawing board.


2016-12-11 05:19

developer   ~0007517

The marking as dirty (touch) come from PathLoadTool.LoadTool.onChanged().

onChanged() gets called several times during the restore process (once for each property). Once the ToolController has "children" those get 'touch'ed each time onChanged() is called.


2016-12-11 05:20

developer   ~0007518

Unfortunately not triggering the touch() (unconditionally) does not fix the naming issue of Contour on restore.


2016-12-11 05:27

developer   ~0007519

The problem is that the logic to assign the proper label (based on the property UserLabel) only exists in Contour.execute(). Contour.onChanged() (which gets called during restore) however uses a simpler logic which leads to the name difference.


2016-12-12 18:35

administrator   ~0007522


Related Changesets

FreeCAD: master c6781442

2016-12-12 19:34:27


Committer: GitHub Details Diff
Merge pull request 0000374 from mlampert/tracker-2770

Path: Assign Contour label on restore fixes 2770
Affected Issues
mod - src/Mod/Path/App/Command.cpp Diff File
mod - src/Mod/Path/PathScripts/ Diff File
mod - src/Mod/Path/PathScripts/ Diff File
mod - src/Mod/Path/PathScripts/ Diff File

Issue History

Date Modified Username Field Change
2016-11-13 00:33 mlampert New Issue
2016-12-10 23:32 mlampert File Added: path1.png
2016-12-10 23:32 mlampert File Added: path2.png
2016-12-10 23:39 mlampert Note Added: 0007513
2016-12-10 23:47 mlampert Note Added: 0007514
2016-12-11 02:26 mlampert Note Added: 0007515
2016-12-11 03:15 mlampert Note Added: 0007516
2016-12-11 05:19 mlampert Note Added: 0007517
2016-12-11 05:20 mlampert Note Added: 0007518
2016-12-11 05:25 mlampert Assigned To => mlampert
2016-12-11 05:25 mlampert Status new => assigned
2016-12-11 05:27 mlampert Note Added: 0007519
2016-12-12 18:35 wmayer Note Added: 0007522
2016-12-12 18:35 wmayer Status assigned => closed
2016-12-12 18:35 wmayer Resolution open => fixed
2016-12-12 18:35 wmayer Fixed in Version => 0.17
2019-07-29 15:07 Kunda1 Changeset attached => FreeCAD master c6781442