Hi Miles,
Thanks for the details. It looks like you’re working from an older version. I recommend testing your scenarios in the latest build, since you’ll be happy to see that for question #2, interpolated string expression syntax highlighting and IntelliPrompt features were added in v25.1. This blog post includes a screenshot of the new functionality.
Regarding question #1, I simplified the scenario into a small document you can paste directly into the main SDI Editor demo in the latest version. The sample includes a comment indicating where the "header" break would conceptually occur once this scenario is fully supported.
using static __ScriptHostVariableContainer;
public static class __ScriptHostVariableContainer
{
public static string App; // Define a static field.
}
// Header ends here
// "App" doesn't seem to be resolved here (top-level)
class Foo {
void Bar() {
// "App" completion works here:
App.
}
}
After pasting the code, I’m seeing that IntelliPrompt resolution for “App” does not work at the top level (near the comment), but it does resolve correctly inside a method. Are you seeing the same behavior on your side? If so, it seems that enabling top‑level resolution to behave like method‑level resolution would give you the result you’re looking for. Can you confirm that sort of update would meet your needs?
Best regards,
[Modified 4 days ago]
Thank you for the prompt response.
After pasting the code, I'm seeing that IntelliPrompt resolution for "App" does not work at the top level (near the comment), but it does resolve correctly inside a method. Are you seeing the same behavior on your side?
Yes, we are seeing the same behavior on our side.
In addition, we have confirmed that "App" does appear as a completion candidate in the following cases:
{} block scope is defined and the user begins typing inside that scope.Based on the above observations, we also tried pre-setting {} in the footer text as a workaround, but this approach did not cause "App" to appear as a completion candidate.
If so, it seems that enabling top‑level resolution to behave like method‑level resolution would give you the result you're looking for. Can you confirm that sort of update would meet your needs?
Yes. Even without direct host variable support, that would meet our needs.
As a follow-up, could you confirm our understanding of the following?
If there is a way to achieve this behavior in the current version, we would appreciate it if you could provide an implementation example.
Thanks,
Please log in to a validated account to post comments.