No longer add dynamic property for alias, simply rely on
get(Dynamic)PropertyByName() to check for aliases.
Add new API PropertyContainer::getPropertyNamedList() so that
ExpressionCompleter can discover properties with aliases.
Cell binding allows one to bind a range of cells of one sheet to another
range of cells of an arbitary sheet, including any empty cells in the
range.
The binding is implemented with PropertyExpressionEngine and
PropertySheet::setPathValue(), which binds a special path of
PropertySheet, such as
.cells.Bind.A1.D1
to an expression, such as
tuple(.cells, <<A2>>, <<A5>>)
The A1 and D1 in the example above specifies the binding start and end
cell address. And <<A2>> and <<A5>> are the range of cells to bind to.
Note that you can use any expression that evalutes to string for the
binding destination, e.g. <<A%d>> % B1, which uses the value inside B1
to construct the binding destination. The '.cells' in the tuple shown
above is an example to bind cells of the same PropertySheet. It can be
change to to reference to any other spreadsheet, even those outside the
current document, e.g. Document#Spreadsheet001.cells
For single range copy, the range selection when pasting determines the
start cell and the number of duplications.
For example, when copying a range A1:B2 (i.e. a 2x2 square) and pasting
into a selection of C1:C5 (i.e. a 5x1 vertical line), the square will be
duplicated once in horizontal, but twice in vertical, resulting new
cells range from C1:D4. This logic is borrowed from google sheet.
For multi-ranged copy, no multi duplication is intended. If more than
one selection range exists before pasting, only the top left cell of
the last selected range is used to determine the starting cell for
pasting. The cells will be copied with the exact cell layout keeping any
empty cells in between. This logic is different from google sheet, where
it disallows unalligned multi-ranged copy, and will condense and
eliminate any empty cells for aligned multi-range copy.
- The thread must not be deeper than the hole.
(One could see that if one used a thread depth dimension and set
it to the same value than the hole depth, the thread was too deep.)
- no keyboard tracking
- don't disable labels since we don't do this for the other dialog labels
- avoid a doubled word in subsequent labels
- further UI file changes are by Qt's Designer
- actually use specified thread depth, fixes issue reported here: https://github.com/FreeCAD/FreeCAD/pull/4274#issuecomment-997787744
- fixes 2 UI enabling issues
- the thread depth cannot be longer than the hole depth
- the hole cannot be deeper than the through-all depth
+ it's an obscure way to clear the error state by instantiating PyException, instead use the clear() method
+ do not handle unknown exceptions because this suppresses all exceptions and thus makes error search more complicated
[PD]: Fix helix property visibility/writeability
* Hide irrelevant and internal helix properties
- The `HasBeenEdited` property is only used internally to check whether to
fill certain other parameters with initial values. So there is no need
show it in the property grid at all.
- The `Outside` property is only used in the subtractive helix and thus
hidden for the additive helix.
* Make derived helix properties read-only
Depending on the input mode, some properties are primary input, others
are derived. Prior to this change, also the derived properties have been
writable but their values are ignored and overwritten on the next
recompute. Now, when changing the input mode, only the primary input
props are writable.
* Reorder some helix properties
This change puts the reference axis and input mode at the top to become
more prominent. Only "Base" and "Axis" are higher in the list for
consistency with the other axis-based features.
Depending on the input mode, either `Growth` or `Angle` is used to create
a conical or flat spiral. The respective other can easily be calculated
to give consistent view. This is already done for the other properties,
e.g. `Height` is calculated from `Pitch` and `Turns`.
With this patch, the same is done for `Angle` and `Growth`.
Discretize of 0.0001 is okay for inches, but for metric <1microns would be quite small, this fixes some issues when generating paths for curves that look inward.
I found following post in the forum: https://forum.freecadweb.org/viewtopic.php?f=15&t=42755
I have experienced similar issues with other curves in my object.
