[Fixed] "Polar Pattern" compatibility between 0.19 and 0.20

[uwestoehr]

In the simple debugging I carried out, it seems the PolarPattern::handleChangedPropertyType isn't being triggered when the user opens a 0.19 file in 0.20 so the number of Occurrences isn't being read in from the file.

Thanks for having a look. So will look why this happens as soon as I find time.

Maybe my debugging skills aren't up to scratch but that's where I concentrated my investigation.

Why such a statement? I asked you and you gave me a valid and valuable answer. Both brings us closer to fix the issue.

[GeneFC]

I played with this a bit, and it appears that a change in property type may be the cause.

I created a simple model with 8 repeats and saved in both version 0.19 (release) and version 0.20 (25065). As noted above, neither file opened correctly in the other FC version. Here are the relevant portions of the document.xml files.

FC Version 0.19.PNG (1.82 KiB) Viewed 1717 times

FC Version 0.20.PNG (1.85 KiB) Viewed 1717 times

I am not even a slight bit conversant with C++, but I would guess that each FC version is looking for a variable that does not exist because it has the wrong property type.

Gene

[uwestoehr]

The problem is that the property handling procedure "handleChangedPropertyType" is not called when opening a document. handleChangedPropertyType should automatically be called and read the XML of the file.

I investigated a bit and handleChangedPropertyType is not called for the PartDesign features
- Helix
- LinearPattern
- PolarPattern

It is however called for the PartDesign feature Draft.

I invested more than hour to find a difference between Draft and Helix that could cause this but failed. Therefore I asked in the developer's forum:
https://forum.freecadweb.org/viewtopic.php?f=10&t=60054

[uwestoehr]

The bug is now fixed with commits
https://github.com/FreeCAD/FreeCAD/commit/9fe1f56824
and
https://github.com/FreeCAD/FreeCAD/comm ... 54135ccfe2

For those interested in the technical details of the bug, see https://forum.freecadweb.org/viewtopic.php?f=10&t=60054

@Forthman, can you please add to your initial post in the title line "[fixed]" when you could confirm it is fixed?

[chrisb]

The bug is now fixed with commits

Thanks

Should this be backported, so that 0.20 models work in 0.19 too?

[uwestoehr]

Should this be backported, so that 0.20 models work in 0.19 too?

Good question. Do we have a policy defined that we try to release only versions of FC that are backwards compatible?
As far as I understood, we don't do this. So for example when you have a file using a PD Helix, it won't work in FC 0.18 since it is a new feature of FC 0.19.

[Syres]

Well, there was a definite policy regarding Techdraw not being backwards, hence the reason for me still having to keep a copy of 0.17 purely for modifying a customer's model and tech drawings even today. the workload to get everything converted is just not worth it.

[chrisb]

Usually we don't do it, and we haven't done it for the sketches between 0.18 and 0.19. And I am myself against extensive backporting, because it is quite natural that the new version has new and improved things.
However, it seems to me that the code can be taken just as is, and it isn't too much what should be backported.

Beyond that, I have absolutely no problem if we leave it as is, and don't load more work on Werner's shoulders.

[GeneFC]

The key question is whether anyone will notice.

Anyone using purely 0.19 will not see the bug, nor will anyone using purely 0.20. I would "guess" that it is far more common to try to open a 0.19 model in 0.20 than vice versa. In that case the bug is fixed.

Are there a lot of instances where someone would routinely open 0.20 models in 0.19? Of course this is not recommended for general use because there are lots of other changes that are not backward compatible.

Gene

[chrisb]

You are right, and even if someone opens such a document from 0.20 in 0.19, it is easy to fix.