Forum Discussion
in many cases, WPFObject recognition does not work with CoreCLR-hosted WPF apps.
- akhilpotla1 day agoNew Contributor
Are there any supported solutions or configuration changes to enable reliable WPFObject recognition with CoreCLR-hosted WPF applications?
If not, are there documented workarounds or alternative object identification approaches recommended for such cases?
- Hassan_Ballan1 day ago
Champion Level 3
Since the same TestComplete project exposes WPFObject correctly in BricsCAD 24 but not in 26, the first thing I would verify is whether BricsCAD 26 is now hosted on CoreCLR (.NET 8) instead of .NET Framework.
If it is running on CoreCLR, I would open a SmartBear support ticket and explicitly confirm whether WPFObject recognition is supported for CoreCLR-hosted WPF applications in your TestComplete version. If CoreCLR hosting is not supported by the WPF plugin, there isn’t a configuration change that will enable WPFObject.
That gives you a clear decision path:
- If CoreCLR is supported → continue troubleshooting WPF configuration (plugins, bitness, load order, etc.).
- If CoreCLR is not supported → accept that WPFObject won’t attach and focus on optimizing UIA usage instead.
If you must stay with UIA, one practical improvement is to avoid deep
UIAObject(...).UIAObject(...).UIAObject(...) chains and instead use FindChild() (with a depth limit) against stable properties like AutomationId, Name, or ControlType. In large UIA trees (common in CAD applications), this is typically faster and more maintainable than expanding full hierarchies in Name Mapping.This approach avoids speculation and gives you a concrete next step depending on what SmartBear confirms.
🤖 AI-assisted response
👍 Found it helpful? Click Like
✅ Issue resolved? Click Mark as Solution