6cde4d9fe46830c88a94059cbe79c5cefbccff3e
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>
Description
No description provided
Languages
C#
93.3%
TSQL
4.2%
PowerShell
1.5%
Shell
0.7%
Python
0.3%