---
name: glue-referenced-file-properties
description: ReferencedFileSave properties whose meaning depends on container type (Screen/Entity/Global), and the two independent property grids that must each hide the ones that don't apply. Triggers: IsSharedStatic, IsDatabaseForLocalizing, GetContainerType, ContainerType.None, ReferencedFileSavePropertyGridDisplayer, MainPropertyGridPlugin, DataUiGrid.MembersToIgnore, crash toggling a checkbox on a file/global content.
---

# ReferencedFileSave Properties: Container-Dependent Meaning, Two Grids to Update

A `ReferencedFileSave` can live in three places - `GetContainerType()`
(`FRBDK/Glue/Glue/SaveClasses/ReferencedFileSaveExtensionMethods.cs`) returns `Screen`, `Entity`, or
`None` (global content, in `GlueProjectSave.GlobalFiles`, no owning `GlueElement`). Several of its
properties only make sense for a subset of those - e.g. `IsSharedStatic` only varies per-instance for
Screen-owned files; Entity-owned files are forced static and global content is *always* static
(`GlobalContentCodeGenerator` never reads the flag - see the constructor comment in
`GlueCommon/SaveClasses/ReferencedFileSave.cs`). Before assuming a property is universally meaningful,
trace whether its consuming code generator (`ReferencedFileSaveCodeGenerator.cs` for element-scoped vs.
`GlobalContentCodeGenerator.cs` for global) actually reads it for every container type.

## Landmine: two independent property grids, both must exclude it

Two separate UIs show `ReferencedFileSave` properties, and neither knows about the other's exclusion list:

| Grid | File | Exclusion mechanism |
| --- | --- | --- |
| Legacy WinForms | `Glue/FormHelpers/PropertyGrids/ReferencedFileSavePropertyGridDisplayer.cs` (`UpdateIncludedAndExcluded`) | `ExcludeMember(...)`, driven by `GetContainerType()`/extension checks |
| WPF "Settings (Preview)" | `OfficialPlugins/PropertyGrid/MainPropertyGridPlugin.cs` (`ShowPropertiesForReferencedFileSave`) | `settingsGrid.MembersToIgnore.Add(...)` - a flat list, doesn't consult container type at all unless you add the check yourself |

Both funnel edits into the same place - `SetPropertyManager.ReactToPropertyChanged` →
`ReferencedFileSaveSetPropertyManager.ReactToChangedReferencedFile`. A property excluded from only one
grid is still reachable (and still crashes if its handler assumes context, e.g. a non-null
`GlueState.Self.CurrentElement`) through the other.

**When a property's meaning/effect depends on container type, put the decision in one shared extension
method (e.g. `ReferencedFileSaveExtensionMethods.GetIsSharedStaticEditable`) and call it from both grids**,
not a condition duplicated in each.

## Two real crashes from this exact gap

- **#2016/#2017** - `IsDatabaseForLocalizing` is conditionally excluded in the WinForms grid (non-CSV
  extensions) but the WPF grid showed it unconditionally; its handler cast `oldValue` without a null
  check. `ReactToChangedReferencedFile` is `internal` with callers that hand over no old value, so a null
  `oldValue` is a legitimate input to any handler added there, not a caller bug to chase upstream.
- **#2018** - `IsSharedStatic` wasn't excluded for global content in *either* grid (only Entity was
  handled). Its handler dereferenced `GlueState.Self.CurrentElement.NamedObjects`, null for a global file.
  The first fix attempt null-guarded the handler instead of hiding the now-provably-meaningless checkbox -
  wrong layer. **If a property is inert for a container type (confirmed by tracing its codegen consumer),
  hide it there; don't just prevent the crash.** A null check treats "shouldn't be interactable" as "should
  render safely," which fixes the exception but leaves a dead control the user can still toggle.

## Related
- `glue-project-codegen` - the code generator pipeline these properties feed into.