boost::filesystem::canonical doesn't resolve non existent file where
boost::filesystem::weakly_canonical does.
Notice boost::filesystem::weakly_canonical only resolve absolute path.
* Part: fix Placement/Shape onChanged() handling
* App: fix property ordering problem when undo/redo
See https://tracker.freecadweb.org/view.php?id=4265#c14271
* Gui: fix undo/redo signaling
Make sure to signal after all properties has been restored
A property _ObjectUUID will be added to an object before it is being to
copied, if the property does not exists. Anoter propert _SourceUUID
property will be added to any copied object, with value set to its
source objct's _ObjectUUID.
* distinguish between temp and cache location
* document's transident directory is created in the cache location
* add functions to access temp and cache location via Python
Any object reference inside this function is treated as hidden to
exclude it from dependency calculation. This function allows some form
of cyclic depdenency.
Merger note: renamed from "HREF" to "HIDDENREF" to avoid confusion with
the standard "hypertext reference" use of HREF.
The problem happens when partial loading is enabled. If document A
contains a link to some object in document B, it will load B as partial
document with only that object and its necessary dependencies. But if
document A contains another link to some object in document C which also
has a link to some object in document B, the link in document C may not
be restored, because document B is partially loaded without the linked
object. This patch will check for this case and reload document B for
more objects.
See an example reported in
https://forum.freecadweb.org/viewtopic.php?p=495078#p495078
Files opened by running `freecad xxxx.FCStd` or similar relative paths could not
be saved because of new code introduced to create parent directories. See
https://github.com/FreeCAD/FreeCAD/pull/4996#issuecomment-922370077 and
https://forum.freecadweb.org/viewtopic.php?f=13&t=62319&p=534156#p534156.
This commit resolves the issue by ensuring the parent path is absolute while
saving. We would probably like to make sure the file name is itself stored with
absolute path, but there's a few problems
1. There may be other occurences where files are loaded with relative paths. So
having a check here is a good idea.
2. Files opened by `freecad xxxx.FCStd` somehow don't have the issue where
renaming parent directory throws an exception on save. Instead the file is saved
in the new location.
* Fix lost filename in err msg
In some circumstances, FileExceptions are constructed empty, then have a
filename assigned to them, but the error message in these scenarios is
left as the default "unknown" one, which is sometimes shown to users.
This change fixes that case to be consistent with instances that are
constructed with the filename.
The exception can happen when trying to save the file in a location that does
not exist, or when the user does not have permission to write there. If it
comes when saving after closing the document, all previous changes can be lost.
Partially fixes issue #4098.
Co-authored-by: Heewa Barfchin <heewa.b@gmail.com>
In these two cases, the project's file will not contain the latest
changes, so returning as if the save is complete is incorrect and can
lead to data loss (such as on app quit).
LGTM points out that the construct use in the loop here "does
nothing" -- that is, it is a conditional whose result is never used.
It is apparently being used simply to ensure that the next() function is
called on each loop iteration, but because sequence may be null, it is
shoehorned into a trinary :? operator. To clarify the intent and ensure
that later readers (including LGTM) do not misunderstand it,
this code is broken out into a more standard conditional construct at
the end of each loop iteration.