| Previous | Next |
| MILEFFECTSERR_UNKNOWNPROPERTY | MILEFFECTSERR_NOINPUTSOURCEATTACHED |
MILEFFECTSERR_EFFECTNOTPARTOFGROUP
MILEFFECTSERR_EFFECTNOTPARTOFGROUP belongs to MIL effect graph ownership and membership. An operation expected an effect to belong to a particular group, but the effect is outside that group. The diagnostic goal for it is to identify the first rejecting object and transition, not merely the final high-level symptom.
Start with the returning API
An effect instance has identity and graph ownership., group membership, insertion, and reuse are not value-copy operations: adding the same live node twice or attaching it to another graph changes ownership semantics even if the effect parameters are identical. Reconstruct the graph by object identity, not by display names or serialized settings.
Inspect the following boundary: group membership and ownership at the moment of the operation.
Reproduce without destructive cleanup
Create fresh effect instances for each graph and log every add, remove, group, and dispose operation. Then test deliberate duplicate insertion as a negative control so cleanup code cannot silently mask ownership mistakes.
- build the group explicitly, add the effect once, and run the same operation before removal.
- When it is returned, rebuild the smallest graph containing only the implicated node and one known input.
- Log ownership changes and graph generation numbers.
- validate the graph before allocating large intermediate resources.
Diagnostic evidence matrix
| Record | Why it matters here |
|---|---|
| Effect instance and owning graph or group identity | Preserving effect instance and owning graph or group identity provides the evidence needed to test this distinction: this differs from EFFECTINMORETHANONEGRAPH, which detects conflicting ownership across graphs. |
| Connector, input, child, listener, property, or transform involved | Recording connector, input, child, listener, property, or transform involved separates the MIL effect graph ownership and membership boundary from a later wrapper symptom. |
| Calculated input and output bounds | In this result diagnostics, recording calculated input and output bounds ties the HRESULT to the MIL effect graph ownership and membership boundary rather than to the final visible failure. |
| Construction sequence and first method returning the HRESULT | Comparing construction sequence and first method returning the HRESULT shows whether this result follows input, object state, or environment. |
Useful comparison axes
| Test | Interpretation | Hold constant |
|---|---|---|
| Same environment, reduced input | If this result disappears with a smaller faithful case, complexity within MIL effect graph ownership and membership is implicated. | Keep effect instance and owning graph or group identity fixed while simplifying calculated input and output bounds. |
| Same input, fresh object generation | If this result changes after rebuilding state, examine ownership across the effect instance, connector builder, graph owner, listener, and bounds calculator. | Place connector, input, child, listener, property, or transform involved on the timeline of the last successful transition. |
| Same operation on a controlled second path | If this result follows one environment, the failure is not explained by source data alone. | Compare visual generation, effect registration, shader profile, rendering tier, and target dimensions while preserving construction sequence and first method returning the HRESULT. |
Limits of this code
This differs from EFFECTINMORETHANONEGRAPH, which detects conflicting ownership across graphs. Do not catch the HRESULT and continue rendering with a partially connected graph; later failures can obscure the invariant that was first violated.
What success must demonstrate
A correction for it should let the operation at the MIL effect graph ownership and membership boundary complete repeatedly under the original supported conditions. Repeat the control that begins with “Build the group explicitly, add the effect once, and run the same operation before removal” and confirm that the following lifecycle step also succeeds. Keep the original failing sample and one deliberate negative case so fallback cannot be mistaken for repair.
Technical references
When it is returned, these references define the public API family, object model, or error list used to interpret this status.
- Microsoft Open Specifications: HRESULT values.
- Microsoft: WPF bitmap effects overview.
- Microsoft: PixelShader class.
- Microsoft: Direct2D custom effects.
- Microsoft: ID2D1TransformGraph.
Looking for a different code? Search another status or error code.