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 -
IsDatabaseForLocalizingis conditionally excluded in the WinForms grid (non-CSV extensions) but the WPF grid showed it unconditionally; its handler castoldValuewithout a null check.ReactToChangedReferencedFileisinternalwith callers that hand over no old value, so a nulloldValueis a legitimate input to any handler added there, not a caller bug to chase upstream. - #2018 -
IsSharedStaticwasn't excluded for global content in either grid (only Entity was handled). Its handler dereferencedGlueState.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.