This fixes a difference between Main code and LS3 Code ported during TNP big merge. The Issue generates a crash if FreeCAD is compiled in Debug Mode: #27489.
Do not directly pass getNameInDocument() to the ostream as this will
set the badbit in case it returns nullptr. As a result no further
output is written to the stream and leads to loss of data.
Instead the returned C string is stored in a local variable and in case
it's nullptr an empty string is passed to the ostream.
At the end of the function writeObjects() it's checked whether the
failbit or badbit is set. If yes an error message is printed and the
failbit or badbit are cleared.
This is supposed to fix the issue 18044.
In case this fix is not sufficient it can be also check for every
object inside writeObjectData()
* Do not raise an exception when saving a document and an object has
'freeze' status because this breaks the project file and may lead
to loss of data.
* Make 'freeze' state persistent
* When toggling 'freeze' status only work directly on the selection.
Do not use in-list or out-list of an object because this makes it
quite inflexible and leads to unpredictable behaviour.
This fixes issue with saving frozen files described in 18806.
Since we are linking to boost anyway, use boost function for case
insensitive string compare. While there, make affected methods accept
std::string arguments, which simplifies code a bit.
It can happen that TransactionFactory::createTransaction() fails to create a transaction object because an unsuitable type is passed
(like BadType) and returns a null pointer.
The calling instances (Transaction::addObjectChange, Transaction::addObjectDel, Transaction::addObjectNew, Transaction::addOrRemoveProperty)
do not check for a null pointer and thus cause a segmentation fault by dereferencing it.
To fix the issue change the above methods to explicitly handle a null pointer.
This fixes issue 21095.
Note: In this case it's caused by the class ViewProviderFace which on purpose isn't added to the type system so that its type will be BadType.
If the property is added to a view provider then in debug mode this will
cause a crash while in release mode this will cause undefined behaviour
because of a static_cast.
To fix crashes remove the assert() and replace the static_cast with
freecad_cast.
Put the reading of each expression of an object into a try/catch block. This is to avoid that all expressions of an object may be lost.
This mitigates the issue 19866
Implement the methods Save() and Restore() for PropertyIntegerConstraint and PropertyFloatConstraint. Handle also the case of a user-defined ranges.
This fixes https://github.com/FreeCAD/FreeCAD/issues/24571.
Hint: For PropertyQuantityConstraint this is not doable because it doesn't support user-defined ranges
