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.
When a Python-based object throws an exception during the restoration
process (e.g. inside `onDocumentRestored`), the error is caught by a
generic `catch(...)` block in `Document::afterRestore`.
Previously, this block swallowed the C++ exception wrapper but failed to
clear the underlying Python error state. Leaving the interpreter in this
"dirty" state caused a segmentation fault or `SystemError` later in the
loading process when C++ attempted to interact with the Python API
(specifically in `App::Application::setActiveDocument`).
This commit adds a check for `PyErr_Occurred()` inside the catch block.
If an error is detected, the traceback is printed to the console for
debugging, and `PyErr_Clear()` is called to reset the interpreter state,
allowing the application to continue loading the document without
crashing.
* #25474 Added read-only warnings when saving documents
Block saving a file and notify user if windows is unable to save to the file for any reason, or the read-only attribute is checked. Also check std::filesystem::perms for write permission and other checks in FileInfo::isWritable(), although it doesn't seem to matter on windows.
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
"Professional CMake" book suggest the following:
"Targets should build successfully with or without compiler support for precompiled headers. It
should be considered an optimization, not a requirement. In particular, do not explicitly include a
precompile header (e.g. stdafx.h) in the source code, let CMake force-include an automatically
generated precompile header on the compiler command line instead. This is more portable across
the major compilers and is likely to be easier to maintain. It will also avoid warnings being
generated from certain code checking tools like iwyu (include what you use)."
Therefore, removed the "#include <PreCompiled.h>" from sources, also
there is no need for the "#ifdef _PreComp_" anymore
Made several fixes to TaskMeasure:
* Move to correct namespace
* Handle possible exception in update() method
* Add null pointer checks for buttonBox
* Cannot use 'Measure::MeasurePython' as template argument in addObject<>
because the macro PROPERTY_HEADER_WITH_OVERRIDE determines the invalid
string 'App::FeaturePythonT<FeatureT>' so that an exception is raised
Note: The changes might fix issue 20304
* Ensure the ::Remove flag of DocumentObject is set to true before calls to breakLinks
* TechDraw: remove then add balloon annotation when changing the SourceView
* Revert "TechDraw: remove then add balloon annotation when changing the SourceView"
This reverts commit 483b4fe4a0715ff63c2669af33fc3beb60a93f54.
* Concatenate all of Document::addObject[s] functions into calls to Document::_addObject
* Fix minor logic errors
* use ::isPerformingTransaction instead of direct operators
* Uniform case for enum
* Remove dupplicate code for Document::removeObject
* Use CamelCase for enum and fix comment
Historically, `App::Document::recompute()` ran entirely on the **main**
(GUI) thread and directly emitted `signalBeforeRecompute()`.
* Add-ons like **Assembly3** and others depend on that signal for
setup/teardown hooks before any recompute work begins.
* After offloading `recompute()` into a background worker thread to keep
the UI responsive, calling `signalBeforeRecompute()` directly from the
worker would break thread-affinity rules and silently break
compatibility with those add-ons.
**Solution**
1. **Introduce a generic hook** (`PreRecomputeHook`) in
**App::Document**:
* A `std::function<void()>` that, if set, is invoked at the very
start of `recompute()`.
* Core code stays Qt-free—only knows to call a callback if one
exists.
2. **Wire up the hook in `Gui::Document`**:
* In the GUI wrapper’s constructor, install a hook that calls
`callSignalBeforeRecompute()`.
* `callSignalBeforeRecompute()` uses `QMetaObject::invokeMethod(...,
Qt::BlockingQueuedConnection)` to enqueue `signalBeforeRecompute()` on
the GUI thread and **block** the worker until it completes.
* If already on the GUI thread, it simply calls the signal directly.
3. **Maintain add-on compatibility**:
* From the add-on’s perspective nothing changes—they still receive
`signalBeforeRecompute()` on the main thread before any recompute work.
* Internally, the recompute body now runs on a worker thread,
improving UI responsiveness without breaking existing hooks.
**Result**
* **Recompute** remains fully backward-compatible for add-ons like
Assembly3.
* **UI thread** still handles all GUI-related signaling.
* **Worker thread** performs the actual heavy lifting, unblocked only
once the GUI is primed and all pre-recompute signals have been
delivered.
* Core: Fixed a bug where an empty document disappears
Created a flag named autoCreated to distinguish an autoCreated
document created in the startup from a manually document.
Implemented a setter and a getter for this new flag.
Added a codition that verifies if a document is autoCreated
when opening another document to close it in the correct case.
Implemented unit tests for theses cases. Fixes#19868.
Signed-off-by: João Neves <joao.antonio.neves@tecnico.ulisboa.pt>
* Tests: Fix failing auto-created document tests
Signed-off-by: João Neves <joao.antonio.neves@tecnico.ulisboa.pt>
* Tests: moved created tests to the existing Document test framework.
Signed-off-by: João Neves <joao.antonio.neves@tecnico.ulisboa.pt>
---------
Signed-off-by: João Neves <joao.antonio.neves@tecnico.ulisboa.pt>
Fixes: Maintaining schemas is difficult and error-prone
- Facilitate easy schemas add, remove, change, etc.
- Remove 14 files containing approx 2,190 lines of if/else code and data
- Place data in one file (UnitsSchemasData.h) using a normalized structure (including special functions)
- Isolate and simplify data operations (code)
- Remove schemas enum to keep data independent of code
- Separate responsibilities: Specifications, data, schemas, schema
- Add schema data 'isDefault'
- Add schema data name
- Prefer algorithms to raw loops
- Add schemas unit tests
- Tweak quantity unit tests
- The location of the documentation is improved (not in the cpp file
anymore but in core-app.dox). This prevents cluttering source with
high-level overviews typical of topic documentation.
- The formatting has been made consistent.
Under certain circumstances the existing code would try to obtain the Label of a DocumentObject after that object had been deleted, causing an access to freed memory and failing to deregister the Label. The latter would lead to phanton Label collisions and unexpected generation of unique labels.
As described in Issue 16849, the existing Tools::getUniqueName method
requires calling code to form a vector of existing names to be avoided.
This leads to poor performance both in the O(n) cost of building such a
vector and also getUniqueName's O(n) algorithm for actually generating
the unique name (where 'n' is the number of pre-existing names).
This has particularly noticeable cost in documents with large numbers
of DocumentObjects because generating both Names and Labels for each new
object incurs this cost. During an operation such as importing this
results in an O(n^2) time spent generating names.
The other major cost is in the saving of the temporary backup file,
which uses name generation for the "files" embedded in the Zip file.
Documents can easily need several such "files" for each object in the
document.
This update includes the following changes to use the newly-added
UniqueNameManager as a replacement for the old Tools::getUniqueName
method and deletes the latter to remove any temptation to use it as
its usage model breeds inefficiency:
Eliminate Tools::getUniqueName, its local functions, and its unit tests.
Make DocumentObject naming use the new UniqueNameManager class.
Make DocumentObject Label naming use the new UniqueNameManager class.
This needs to monitor DocumentObject Labels for changes since this
property is not read-only. The special handling for the Label
property, which includes optionally forcing uniqueness and updating
links in referencing objects, has been mostly moved from
PropertyString to DocumentObject.
Add Document::containsObject(DocumentObject*) for a definitive
test of an object being in a Document. This is needed because
DocumentObjects can be in a sort of limbo (e.g. when they are in the
Undo/Redo lists) where they have a parent linkage to the Document but
should not participate in Label collision checks.
Rename Document.getStandardObjectName to getStandardObjectLabel
to better represent what it does.
Use new UniqueNameManager for Writer internal filenames within the zip
file.
Eliminate unneeded Reader::FileNames collection. The file names
already exist in the FileList collection elements. The only existing
use for the FileNames collection was to determine if there were any
files at all, and with FileList and FileNames being parallel
vectors, they both had the same length so FileList could be used
for this test..
Use UniqueNameManager for document names and labels. This uses ad hoc
UniqueNameManager objects created on the spot on the assumption that
document creation is relatively rare and there are few documents, so
although the cost is O(n), n itself is small.
Use an ad hoc UniqueNameManager to name new DymanicProperty entries.
This is only done if a property of the proposed name already exists,
since such a check is more-or-less O(log(n)), almost never finds a
collision, and avoids the O(n) building of the UniqueNameManager.
If there is a collision an ad-hoc UniqueNameManager is built
and discarded after use.
The property management classes have a bit of a mess of methods
including several to populate various collection types with all
existing properties. Rather than introducing yet another such
collection-specific method to fill a UniqueNameManager, a
visitProperties method was added which calls a passed function for
each property. The existing code (e.g. getPropertyMap) would be
simpler if they all used this but the cost of calling a lambda
for each property must be considered. It would clarify the semantics
of these methods, which have a bit of variance in which properties
populate the passed collection, e.g. when there are duplicate names..
Ideally the PropertyContainer class would keep a central directory of
all properties ("static", Dynamic, and exposed by ExtensionContainer and
other derivations) and a permanent UniqueNameManager. However the
Property management is a bit of a mess making such a change a project
unto itself.
This adds isNullOrEmpty string helper that cheks if string is... well
null or empty. It is done to improve readability of the code and better
express intent.
