Hi Werner,
What was agreed is ready for a pull request (I think).
https://github.com/abdullahtahiriyo/Fre ... master.git
branch: Sketcher_properties_eventdriven_rebased
[Merged] Modify value of datum constraints from properties
Re: [Merged] Modify value of datum constraints from properti
Merged. Need some tweaks for Windows, removed some unused headers and improved whitespaces.
Re: [Merged] Modify value of datum constraints from properti
Thanks for all your efforts Abdullah and Werner
For anyone else wondering, here are some screen shots.
Firstly if you have a sketch like this one that only uses non datum constraints (datum constraints are constraints that have a value e.g. length but not like co-incidence or parallel) it looks like this...basically it of course does nothing
However if you have a sketch with datum constraints like this one, which has a horizontal constraint (in this case automatically named) and a Vertical constraint which I renamed vertical1, looks like this when you first open it
When you expand the property editor it looks like this , and of course you can edit the values without needing to set the sketcher into edit mode
Looks great guys!
Jim
For anyone else wondering, here are some screen shots.
Firstly if you have a sketch like this one that only uses non datum constraints (datum constraints are constraints that have a value e.g. length but not like co-incidence or parallel) it looks like this...basically it of course does nothing
However if you have a sketch with datum constraints like this one, which has a horizontal constraint (in this case automatically named) and a Vertical constraint which I renamed vertical1, looks like this when you first open it
When you expand the property editor it looks like this , and of course you can edit the values without needing to set the sketcher into edit mode
Looks great guys!
Jim
Re: [Merged] Modify value of datum constraints from properti
great! feels right at home, as if it was always there
Re: [Merged] Modify value of datum constraints from properti
Thanks for all your efforts Abdullah and Werner
Thanks for the compliments!Thanks for all your efforts Abdullah and Werner
Well, this time Werner has really put his coding gloves to help me out, so the merit should go to him.
If todays pull-request goes though, I am sorry Jim the screenshots are no longer accurate Just kidding, it has changed a little, but your screenshots really help see the new feature.
For Windows I can only say sorry, I do not have Windows. Can not check the code there.Merged. Need some tweaks for Windows, removed some unused headers and improved whitespaces.
I checked your commit:
https://github.com/FreeCAD/FreeCAD_sf_m ... 9080ee37c6
You removed GuiExport (which I thought (read somewhere) that was necessary to export the symbols in the library in Windows (it is defined to nothing in Linux). Why is this?
You added an endofline at the end of each file (is this part of the c++ specification or windows specific?).
You cleaned up a lot of unneeded headers. Sorry I inhereted a lot from PropertyItem.h and forgot to clean up.
For the improved whitespaces, keep saying it, I am trying ... (though I should probably try harder).
Re: [Merged] Modify value of datum constraints from properti
It depends on in which module an export macro is defined. It's always like this that in the module which provides the classes the macro is defined as __declspec(dllexport) while in any other module which uses the classes of a module the macro is defined as __declspec(dllimport), i.e. it's actually an import macro.You removed GuiExport (which I thought (read somewhere) that was necessary to export the symbols in the library in Windows (it is defined to nothing in Linux). Why is this?
So, in this case GuiExport is used inside FreeCADGui to export classes and thus is defined as __declspec(dllexport) while in other modules it is defined as __declspec(dllimport). Now when you use GuiExport in SketcherGui to try to export classes you get linker errors -- so it's wrong macro there. And since it's rather unlikely that another module needs to access a PropertyConstraintListItem directly we do not even have to export it. The correct macro would have been SketcherGuiExport.
Many editors give you a warning about this. And IIRC if you increase the warn level of the compiler he will complain, too.You added an endofline at the end of each file (is this part of the c++ specification or windows specific?).
It's just my aesthetic preference to avoid lines with only spaces or multiple empty lines.For the improved whitespaces, keep saying it, I am trying ... (though I should probably try harder).