this is a good "discovery". Sounds like it makes "valueChanged" behave more like "editingFinished".
The latter is important because a dialog in which I can change something but don't see any effect is useless. The detail dialog is there to be able to find the right location and size. This involves fine-tuning, so a millimeter more or less. If I would need to close the dialog just to see the effect, then open it again, then changing another mm, then close etc. as it is now, having a dialog is no help.
Yes, I understand this. But in the current configuration, there is no need to close the dialog to see the update. The tab key will trigger an update, as will changing focus to another widget. The enter key should do it also, but that is trapped somewhere and never delivered to the widget in the dialog.
The issue was that the recompute was being triggered by the dialog for every keystroke in the changed field. So if you wanted to change the X position of the highlight from 350 mm to 500 mm the recalculation would be done approximately 6 times - 3 backspaces to remove the old value, then 3 keys to enter the new value.
A similar condition occurs when a recompute is triggered by the onChanged method. The changed signal occurs for every digit changed. onChanged should only call recompute if the execute method is very light - as in Annotation, say.
I also think that we have a phantom discussion in this respect because of course as user I always want to see the effect immediately. If I e.g. drag a complex 3D model in FC, of course this involves a lot of computations, but this is CAD. Nobody will use a netbook for CAD because he knows it might become dog slow.
Not an expert in Coin, but I don't believe a drag in the 3D window involves a lot of calculation for FC, just a tweak or two to the existing scene graph.
In TD also, a drag should not recompute geometry as the position on the page is not relevant to the projection.
Besides this, could you please provide a sample file where you thin the user is lost when a dialog makes e.g. 10 recomputes in a row? I still cannot see any problem because moving a 3D model recomputes much more and e.g. in the Detail dialog the user clicks just a few times.
I believe I was using "screwjack_assembly.fcstd". The initial section origin point is too far to the right, and trying to move the position back to the origin triggered the loop/slow response.
- This PR does not fix the issue that the property "HighlightLineColor" should be hidden in the DetailView beaus there is no "ViewProviderDetail" yet and I don't know the reason.
The drawing process for the detail view is the same as for the regular view (except for the "matting" overlay), so it uses the same view provider as the regular view.
The "HighlightLineColor" property can be selectively hidden by testing if the feature is a DrawViewDetail, and setting App::Property::Hidden appropriately.