Two follow-on fixes after the MxValueDetails reader correction:
1. AttributeValueDetails was falling through to the package-binary
fallback even when MxValueDetails returned Supported=true. Cause:
`ReadString(direct, "Supported")` reflects on an anonymous type via
InvokeMember, which returned an empty string under
`BindingFlags.IgnoreCase`, making the StringEquals check fail.
Replace with a typed `Type.GetProperty("Supported").GetValue(direct)`
bool check via the new IsDirectSupported helper.
2. ObjectScript (the `scripts get` body retrieval) skipped the live
attribute path entirely and went straight to the package-binary
parser. The parser truncates strings at certain delimiters (e.g.
marker text containing `\n` or `=` came back as just the prefix).
Now ObjectScript tries `obj.ConfigurableAttributes[<script>.<field>]
.value.GetString()` first and only falls back to the package body
when the direct read returns null. Matches the pattern in
AttributeValueDetails. The package fallback survives for cases
where direct GRAccess doesn't surface the attribute.
End-to-end live round-trip on $DelmiaReceiver.ProcessRecipe.ExecuteText
with marker `// scripts-get round-trip marker\nMe.RecipeDownloadFlag = false;`:
scripts get -> Source: direct-graccess
Body: <marker>
attribute value get -> Value: <marker>
Both readers return the same content the writer wrote. Field then
restored to the original `Me.RecipeDownloadFlag = false;`.
Tests still 66/66.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The MxValueDetails reader was the root of the false "writeback gap"
diagnosis. Three problems compounded:
1. ReadProperty(attr, "Value") used case-sensitive late-binding via
InvokeMember. The COM-side property is exposed as `value` (lowercase)
on IAttribute, so the lookup silently returned null.
2. Even if the MxValue was retrieved, the accessor probe loop
(Invoke(value, "GetBoolean") -> "GetInteger" -> ... -> "GetString")
relied on IDispatch late-binding. The MxValue interface's accessors
are vtable-only — they aren't reachable through IDispatch — so every
call threw, and the reader reported "no supported scalar accessor
succeeded" even when the typed accessor would have returned the
value cleanly.
3. The probe loop ordering put GetString last, so for any value that
somehow survived the type errors silently, an earlier accessor could
have returned a wrong-typed result.
Fix:
- Add `BindingFlags.IgnoreCase` to ReadProperty + Invoke. COM IDispatch
is case-insensitive at the IDL level; .NET InvokeMember is not unless
explicitly told to be. Comment explains the trap.
- AttributeValueDetails now uses typed `attr.value` (and falls back to
the same lookup via obj.ConfigurableAttributes when the runtime proxy
returns null), bypassing the late-binding gap entirely.
- MxValueDetails casts to IMxValue and dispatches on
GetDataType().ToString(), calling the typed scalar accessor for the
declared type (GetBoolean / GetInteger / GetFloat / GetDouble /
GetString / GetElapsedTime). MxBigString and MxInternationalizedString
share the GetString path. MxTime is left as a follow-up; its
VBFILETIME field layout differs across interop builds.
- Replaced the misleading "Attribute value is not exposed" / "no
scalar accessor succeeded" messages with specific diagnostics that
identify the actual failure (wrong type cast, typed accessor exception,
unhandled MxDataType).
Live verification on $DelmiaReceiver.ProcessRecipe.DeclarationsText:
BEFORE fix: `attribute value get` → Supported: false, Value: null,
"Attribute value is not exposed by this GRAccess attribute."
AFTER fix: `attribute value get` → Supported: true, DataType: MxString,
Value: "// roundtrip-test marker (graccesscli scripts set
--field DeclarationsText)\n"
The reader now correctly surfaces the value graccesscli's writes have
been persisting all along. This is the gap that produced the "writeback
gap" mirage in the previous round of investigation.
Tests still 66/66.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
I was wrong. AVEVA Tech Note 537 ("Creating an Application Object Script
Using GRAccess", April 2008) documents the supported pattern:
ConfigurableAttributes[<script>.<field>].SetValue(MxValue) inside a
CheckOut/Save/CheckIn cycle. graccesscli's existing
FindAttributeForMutation already follows this — writes to MxCategoryPackageOnly_Lockable
script-text fields persist correctly.
The earlier "writeback gap" diagnosis was a phantom caused by a reader-side
issue. `object attribute value get` against a script body returns
"Supported: False / Attribute value is not exposed" because
MxValueDetails uses a case-sensitive `ReadProperty(attr, "Value")` lookup
plus an accessor probe (GetBoolean -> GetInteger -> GetFloat -> GetDouble
-> GetString) that can fall through silently for some MxValue shapes. The
COM-side property is exposed as `value` (lowercase), readable as
`attr.value.GetString()` -- which the live probe at
`analysis/ide-edit-investigation/probe_setvalue/` does and confirms the
post-write content matches the marker exactly.
Live verification on $TestMachine.UpdateTestChangingInt.DeclarationsText
and $DelmiaReceiver.ProcessRecipe.{ExecuteText,DeclarationsText}:
=== verdict ===
marker landed on same-proxy ConfigurableAttributes: True
marker landed on same-proxy Attributes : True
marker landed on fresh-proxy ConfigurableAttributes: True
marker landed on fresh-proxy Attributes : True
The probe also confirmed that two earlier graccesscli `object scripts set`
invocations (which I had wrongly believed failed) had persisted -- the
marker text I wrote previously was still on disk in
ProcessRecipe.{ExecuteText,DeclarationsText} when read directly via
attr.value.GetString(). The probe restored both fields to their original
values.
This commit:
- Updates the misleading [Command(...)] / [CommandOption(...)]
descriptions in GRAccessSurfaceCommands.cs back to honest versions
citing TN-537.
- Restores the --file-using examples for `object scripts set` and
`object scripts create` across script-editing.md, llm-integration.md,
usage.md, and zb-testmachine.md.
- Removes the test that asserted the (wrong) EnsureMutableViaSetValue
guard. Re-aims ScriptCommandDescriptions_… at the corrected wording.
- Removes two leftover EnsureMutableViaSetValue calls in the trigger-period
/ trigger-type write paths (both targeted MxCategoryWriteable_C_Lockable
attributes; would never have fired even if the helper still existed).
- Adds analysis/ide-edit-investigation/REPORT.md (replacing the earlier
wrong report) plus the probe sources under probe_setvalue/.
The MxValueDetails reader gap (case-sensitive ReadProperty + accessor
probe) is a real follow-up: `object attribute value get` should
case-insensitively read `value` and try GetString first when the
underlying MxValue.DataType is MxString. Out of scope here -- that's a
separate, smaller fix.
Test count delta: 67 -> 66 (-2 wrong tests, +1 corrected description test).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a new "Editing Script Content" section to script-parsing.md that
explains the IAttribute.SetValue silent-no-op behavior on
MxCategoryPackageOnly* attributes, enumerates which ScriptExtension
fields fall on each side of the boundary (text fields = no, trigger
settings = yes), names the EnsureMutableViaSetValue safety check that
landed in bd95ace, and includes a one-liner for inspecting any
object's package-only attributes via `object attributes --configurable`.
Closes the documentation gap surfaced when validating the round-trip
script edit on \$DelmiaReceiver.ProcessRecipe — the previous docs
described the read path comprehensively but said nothing about which
attributes can actually be written.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Investigation findings: IAttribute.SetValue silently no-ops for any
attribute whose AttributeCategory starts with `MxCategoryPackageOnly`.
The COM call returns Successful=true and the dispatcher reports OK,
but a verify-read via direct IAttribute.GetValue confirms the value
is unchanged.
Discovered while validating the new --field flag round-trip on
\$DelmiaReceiver.ProcessRecipe.ExecuteText:
- BEFORE write: ExecuteText body = `Me.RecipeDownloadFlag = false;`
- WRITE: scripts set --field ExecuteText --file marker.txt → OK
- AFTER write: ExecuteText body = `Me.RecipeDownloadFlag = false;`
(UNCHANGED — the marker prefix from marker.txt is absent)
- ConfigurableAttributes shows `ProcessRecipe.ExecuteText` category =
`MxCategoryPackageOnly_Lockable`. Same for DeclarationsText,
StartupText, ShutdownText, OnScanText, OffScanText, Expression.
- Per docs/script-parsing.md:8, "Object-level scripts ... may appear
as attributes, extension attributes, or only inside exported object
packages" — script-text fields are in the third bucket.
Trigger settings (TriggerType, TriggerPeriod) are
`MxCategoryWriteable_C_Lockable` and remain effective via SetValue —
verified by `scripts settings set --trigger-period-ms 1000` returning
OK on a clean checkout state.
Add `EnsureMutableViaSetValue(IAttribute, name)` helper that throws
InvalidOperationException with a clear remediation hint when called on
a package-only attribute. Wired into three write sites:
- `case "value-set"` (object attribute value set)
- `ObjectScriptSet` (scripts set body writer)
- `SetScriptSettings` Expression branch (the one trigger-related field
that's package-only; TriggerType/TriggerPeriod stay unguarded)
Validation against live ZB galaxy:
- Before fix: `scripts set --field ExecuteText` returned
`success: true` but didn't mutate the body.
- After fix: same call returns `success: false` with
`"Attribute 'ProcessRecipe.ExecuteText' has category
'MxCategoryPackageOnly_Lockable'. Package-only attributes silently
no-op via IAttribute.SetValue and can only be edited through the
package import/export round-trip..."` (exit code 1).
- `scripts settings set --trigger-period-ms 1000` against the same
script: still OK (TriggerPeriod is Writeable_C_Lockable).
The real fix for editing script bodies is the package-rewrite path —
export `.aaPKG`, modify the binary script-extension records, re-import
via `galaxy.ImportObjects`. graccesscli already has the read half
(`PackageSnapshotParser.Parse`); the write half is a separate followup.
61 → 63 → 63 (no test count delta this commit; the new helper is exercised
end-to-end by the live validation above; unit tests for the failure path
require a mock IAttribute proxy that's out of scope here).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three additions to the script editor commands. Each one closes a real
gap surfaced by the round-trip-test against \$DelmiaReceiver.ProcessRecipe.
1. `object scripts set --field <name>` — explicit text-field selection.
Previously `scripts set` always wrote to <Name>.ExecuteText (via
ScriptAttributeName's default). To rewrite DeclarationsText / StartupText
/ ShutdownText / OnScanText / OffScanText / Expression, callers had to
pass the full attribute name as `--script Foo.StartupText`, which is
brittle. The new `--field` flag accepts any of the seven canonical
ScriptTextSuffixes and composes <script>.<field> directly. Validates
against the suffix list so an unrecognised --field surfaces a friendly
error rather than a downstream FindAttributeForMutation failure.
Default behavior (no --field) is unchanged: ExecuteText.
2. `object scripts settings set --lock-trigger-type` — parallel to the
existing --lock-trigger-period. After writing TriggerType the new flag
calls SetLocked(MxLockedInMe), matching the lock pattern on the period
field. Without it, --trigger-type writes the value but leaves the
attribute unlocked.
3. `object scripts delete` — script-named alias for the existing
extension-delete subcommand. Wraps obj.DeleteExtensionPrimitive(
"ScriptExtension", scriptName) inside AtomicObjectEdit (checkout / save
/ checkin). Removes the burden of remembering the generic
`--extension-type ScriptExtension --primitive <Name>` form.
Test count delta: 61 -> 63 (+2 command-shape assertions for the new
ObjectScriptsSetCommand and ObjectScriptsDeleteCommand).
Live round-trip-test against \$DelmiaReceiver.ProcessRecipe:
- `--field DeclarationsText` write composed `ProcessRecipe.DeclarationsText`,
CheckOut/Save/CheckIn all returned OK.
- `--field ExecuteText` round-trip same.
- A subsequent re-read shows the original body, suggesting that
IAttribute.SetValue silently no-ops for ScriptExtension text fields on
this GRAccess version (or the package-export reader pulls from a
different snapshot than the just-saved revision). This is upstream of
the editor surface — the new flags route correctly to the same SetValue
path that scripts set already used. Diagnosing the SetValue
ineffectiveness for script-text fields is a separate followup that
should look at IScriptExtension-specific COM interfaces (per
docs/script-parsing.md:8 "Object-level scripts are less direct").
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`object scripts list` previously walked obj.Attributes through a
substring heuristic (`IsScriptAttribute`) that matched any name
containing "script", "expression", "execute", "startup", "shutdown",
or "scan". Two failure modes:
- "deSCRIPTion" contains "script", so every `MoveIn*.Description` /
`MoveOut*.Description` attribute on `$MESReceiver` (and any other
object with `.Description` UDAs) was mis-emitted as a script.
- `ScanState` / `ScanStateCmd` (ordinary attribute UDAs) leaked in via
the "scan" keyword.
Net result on $MESReceiver: 25 entries, all false positives, zero
true ScriptExtensions.
The GRAccess COM API does not expose an `IScriptExtension` enumerable
(verified against ArchestrA.GRAccess.dll string table — only
`AddExtensionPrimitive` / `DeleteExtensionPrimitive` /
`RenameExtensionPrimitive` mutators exist). The only attribute-side
signal that an object carries a real ScriptExtension is the canonical
text-attribute suffix list documented in docs/script-parsing.md:
ExecuteText, DeclarationsText, StartupText, ShutdownText, OnScanText,
OffScanText, Expression.
Replace `IsScriptAttribute` with `ScriptExtensionPrefix(name)` that
detects exactly those suffixes, then group attributes by prefix:
- Each ScriptExtension yields one logical entry named by its prefix.
- The Fields[] list reports which text attributes are present.
- Sibling `<prefix>.TriggerType` / `<prefix>.TriggerPeriod` attributes
are surfaced as TriggerType / TriggerPeriod when present.
- ExtensionType is always "ScriptExtension".
Outer `ObjectScripts(IGalaxy, IgObject, PackageSnapshot)` updated to:
- Thread ExtensionType / Fields / TriggerType / TriggerPeriod through.
- Look up body content by prefix first, then fall back to
`<prefix>.ExecuteText` (the package's serialized bodies are keyed
by full attribute name).
- Mark every `<prefix>.<field>` as emitted so the package-fallback
branch doesn't re-emit each text field as its own entry.
Drop dead `IsScriptAttribute` (no other callers).
Validation against live ZB galaxy:
- $MESReceiver: 25 → 0 (correct: no ScriptExtensions on this template)
- $TestMachine: 1 entry — UpdateTestChangingInt with body
"Me.TestChangingInt = System.Random().Next(1,1000);" + all 7 fields
+ trigger metadata.
- $DelmiaReceiver: 2 entries — ProcessRecipe + Reset, both with bodies
("Me.RecipeDownloadFlag = false;") + trigger metadata.
61/61 existing tests pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Five tools under one repo, all docs organized per DOCS-GUIDE.md:
- aalogcli: .NET 4.8 / x86 CliFx CLI for reading System Platform binary
logs (*.aaLGX) for LLM debugging, built on aaOpenSource/aaLog. Commands:
last, tail, range, unread, fields. Stable JSON envelope under --llm-json.
Build template under lib/build/ for rebuilding aaLogReader.dll.
- aot: ArchestrA Object Toolkit 2014 v4.0 reference material. Dev guide
(Markdown converted from CHM), API reference for the ArchestrA.Toolkit
namespace, and the Monitor / Watchdog VS sample solutions.
- graccesscli: .NET 4.8 / x86 CliFx CLI that automates Galaxy
configuration via the ArchestrA GRAccess COM interop. Includes session
daemon, IPC protocol, and llm-json envelope contract.
- grdb: SQL/DDL exploration of the Galaxy Repository database. DDL
captures, reusable queries, hierarchy / contained-name <-> tag-name
translation notes.
- histdb: LLM-oriented reference for AVEVA Historian retrieval. INSQL
linked-server, extension tables, every wwXxx time-domain extension,
every retrieval mode, alarm/event SQL recipes, REST API. Distilled
from the 243-page Historian Retrieval Guide.
Root contains:
- CLAUDE.md: thin index pointing into each tool's README.
- DOCS-GUIDE.md: doctrine for organizing docs for LLM consumption.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Joseph Doherty