When the aggregate uses variables, we need to ensure that the
cache key correctly considers the current value of ALL those
variables. Otherwise we'll return incorrect results when
an expression is re-evaluated after changing the variable
value for the context.
Fixes use of aggregate function with @symbol_label in legends.
Fixes#58221
QgsExpressionContext, providing a place for layers loaded
during expression preparation/evaluation to be stored
There are no destination stores set by default. The store
is likely to be set only in a limited number of circumstances,
eg in expression contexts used by Processing where we already
have a logical temporary layer store to use (via QgsProcessingContext)
with an expression context
This allows the various expression functions which can refer to
layers to also locate layers stored in these additional,
non-QgsProject::instance, store.
The immediate use case is paving the way for expressions to access
temporary layers created during the execution of processing jobs
(ie model steps). (This is just an API building block toward that
goal)
This enum was forcing an include of qgscoordinatetransform.h within the
widely used qgsabstractgeometry.h header, causing an absolute explosion
of includes of a bunch of very heavy header classes all across QGIS. By
removing the forced include we can avoid a ton of unwanted includes
and make wider use of forward declarations...
This can be checked by expression functions which are costly to
evaluate (e.g. those which fetch features from a layer) and which
would benefit from early exits when the results of the expression
evaluation are no longer needed (e.g. due to canceling a layer
rendering, etc)
styling when rendering polygon rings
The variable is available whenever a polygon outline is being
rendered (e.g. as a simple line, marker line, etc). It will
be set to 0 for the exterior ring, and 1, 2, 3... for interior
rings.
For the c++ api dox this expands to "\c nullptr" (the
\c directive indicates a code literal value), and for sipify/Python
it expands to ``None`` (`` is sphinx annotation for literal values)
Makes for nicer dox for both c++ and Python!
as well as just variable names
In some cases contexts may provide specific functions of use
to that context, or more generally there may be functions we want
to highlight for a particular expression builder (e.g. highlighting
to_dms in the grid annotation builder)
The value relation widget filter expression can now use two
new functions/variables that have access to the current
values and geometry of the form being edited.
This allows for dynamic filtering (drill-down) as explained
in the crowdfunding page:
https://north-road.com/drill-down-cascading-forms/
The new functions/variables are:
Function:
get_current_form_field_value( 'FIELD_NAME' )
Variable:
@current_form_geometry
