Currently if user selects object with `Selectable=false` property which
is nested inside a Part container, for example `Part->Body->Pad`, parent
Part container will get highlighted in the 3D view, even though the user
clicked on a non-selectable child object.
Cause of that is that tree view's `getTopParent()` function resolves
nested objects selections to their top-level container. When a Pad
inside Part is selected, `SoFCUnifiedSelection` was only checking Part's
`isSelectable()` status, even though the target is `Pad`.
So the fix is to resolve subname to get the final target object and
checks its `isSelectable()` status before checking for highlighting.
* [PartDesign] create a new Gui Unit Test for the creation of a sketch and...
...improve the Selection Filter syntax error to show where it's being generated from.
* [PartDesign] address Lint feedback
* PD/Tests: Ensure test file does not exist before SaveAs
---------
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
only 4 of these warnings are still relevant, CMake shall be used to disable them
Compiler definitions:
NOMINMAX:
* is already globally defined in SetGlobalCompilerAndLinkerSettings.cmake
WIN32_LEAN_AND_MEAN:
* use CMake target_compile_options on relevant targets
Warnings that still occur:
C4251, C4273, C4275: all related to dllimport / export
* use CMake target_compile_options on relevant targets
C4661: no suitable definition provied for explicit template instantiation request
* triggered in Mesh because of Vector3D in Base - not all functions are defined in header
* use CMake target_compile_options on relevant targets
Warnings that are Currently not triggered (fix code if they appear again):
C4005: macro redefinition
C4244: argument conversion, possible loss of data
C4267: conversion from size_t to type, possible loss of data
C4305: truncation from type1 to type2
* only occurrence disabled in Reader.cpp
C4522: multiple assignment operator specified
C5208: unnamed class in typedef name
Obsolete Compiler warnings:
C4181: not mentioned in Microsoft docs anymore
C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
* throw(optional_type_list) deprecated in C++17
C4482: nonstandard extension used: enum 'enumeration' used in qualified name
* not generated for compilers that support C++11
C4503: 'identifier': decorated name length exceeded, name was truncated
* obsolete since Visual Studio 2017
C4786: not mentioned in Microsoft docs anymore
+ added some better grouping for items, which are assigned per object
right now. For example, if we exceed 10 items per object it gets an
additional group.
Co-authored-by: realthunder <realthunder@users.noreply.github.com>
As the title says, this is from RT's fork. I only adjusted it a little
bit and removed pie selection which was previously in the
implementation.
To activate context menu - "G, G", then if it can't resolve edges vs
faces, it adds QMenus on top to let user decide which one to select.
Co-authored-by: tetektoza <tetektoza@users.noreply.github.com>
When user has specified a filter for a multi selection attempt, for
example Ctrl + clicking on a disallowed edge, the visual highlighting of
previously selected valid objects (that filter allowed) would disappear,
even though they were still internally valid in selection system.
The root cause of that was that when `addSelection()` failed, the code
still applied a `SoSelectionElementAction::None` to the scene graph
path, which was clearing visual highlighting for all objects in that
path, including those valid selection.
So, the fix is to set `pPath` to `nullptr` if selection fails, to
prevent any visual action from happening and being applied, in essence
leaving correct (and existing) selection untouched.
`std::shared_ptr` default-initializes to `nullptr`, so there is no need
to do it manually, and in the current code the initialization is in the
wrong order (so generates a compiler warning).
