Bug: Edit Hole Dialog inaccessible after loading from file

About the development of the Part Design module/workbench. PLEASE DO NOT POST HELP REQUESTS HERE!
Post Reply
rfbug
Posts: 1
Joined: Tue Dec 17, 2019 1:59 pm

Bug: Edit Hole Dialog inaccessible after loading from file

Post by rfbug » Thu Dec 19, 2019 9:31 am

Hello,

my name is Michael, I just started to explore mechanical design and only recently started using FreeCAD ... and this my first post, so please bear with me :)

The issue:
Creating a threaded hole with metric profile and a type other than None, Countersink or Counterbore, will make the hole editing dialog inaccessible after saving/reloading the file. (A minimal working (sic) example is attached.)

During file loading you are presented with the following error texts:
"Cannot get value from invalid enumeration" and
"Thread size out of range"

(Actually you will already be presented the "Thread size out of range" message with any threaded hole, but no further consequences seem to come with that... most importantly you can still edit the hole feature.)


I have tried to track the issue down. This is what i have come up with so far:
Thread types and diameters and other properties are described as enumerations. (https://github.com/FreeCAD/FreeCAD/blob ... reHole.cpp) Depending on the type of thread (e.g. UNC or metric) the enumerations (e.g. for diameter) are dynamically loaded. Changes in a parameter are handled by the onChanged method. As long as changes occur consistently through the UI all seems fine. As soon as you load from file (Hole::Restore()), order is not guaranteed anymore and inconsistencies occur.

In this particular case HoleCutType = 3 is read from file, while ThreadType is still None, so only HoleCutTypes 0, 1 and 2 are defined. onChanged fails and ThreadType never gets updated.

The same mechanism applies for the thread size issue, however in that case the onChanged function does not fail completely and still updates ThreadType. Since onChanged is called several times (see below), the problem is (unintentionally) rectified the next time and the threadSize gets set correctly.

The way this feature is implemented, it imposes an order in which the onChanged events have to be sent. (e.g. first ThreadType, then ThreadSize, ...) This might have been the intention of the updateProps() function called from Hole::Restore(). (Read all the values from the file first and then with a consistent set of values update the properties with a correctly ordered sequence of onChanged calls) This however does fail, since during Restore each enum by itself calls onChanged when a new value is set (App/Propertyc.cpp Property::hasSetValue()).


I think the following two threads touch on the same issue:
https://forum.freecadweb.org/viewtopic.php?f=19&t=39113
https://forum.freecadweb.org/viewtopic.php?t=27975


For completeness, my version information below. (The issue is the same in current however.)

OS: Manjaro Linux
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16146 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 0.18.4)
Hash: 980bf9060e28555fecd9e3462f68ca74007b70f8
Python version: 3.6.7
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)

Michael
.
Attachments
hole_bug2.FCStd
(13.33 KiB) Downloaded 5 times
Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests