BlockDialog / Tree / UIBlock — Reference Guide has no hosting/docking API

Bottom line: searched the actual NX Open Reference Guide (not just the Programmer's Guide) and confirmed there is no documented way to host, embed, reparent, or dock a Block UI Styler dialog (or its Tree/Node control) into a custom window or a ResourceBarManager resource-bar tab. The reference guide only supports the two paths we already knew about: launch it as its own dialog (BlockDialog.launchInDialogMode), or build a fully separate hand-rolled UI (Qt/WinForms/etc.) hosted via ResourceBarManager::GetWindowHandle.

How this was found

The NX Open Reference Guide (distinct from the Programmer's Guide) is a genuine per-language generated API reference (Javadoc-style for Java, similar for .NET/C++). It's reachable from Support Center search results titled NXOpen Java API Reference / Open for Java Reference Guide, doc id PL20220512394070742.open_java_ref. The outer docs.sw.siemens.com wrapper still uses an iframe, but — unlike the normal id="xhtml" topic pages — this iframe has no id/name attribute, so grab it via document.querySelectorAll('iframe')[0] instead of getElementById('xhtml'). Internally it's a real javadoc frameset (OVERVIEW / PACKAGE / CLASS / USE / TREE / DEPRECATED / INDEX / HELP nav bar); package/class links must be clicked from within the iframe document (doc.querySelectorAll('a')) — directly constructing and navigating to the underlying https://docs.sw.siemens.com/documentation/external/<id>/.../nxopen/blockstyler/ClassName.html S3-style URL returns AccessDenied (no session/signing cookie), so you must navigate via the wrapper page and click through the iframe.

What was checked, exhaustively

Package: nxopen.blockstyler ("Provides classes and interfaces for Block Styler"). Note: the class is an interface named BlockDialog, not BlockStylerDialog (that name doesn't exist in the API — it's the name of the designer tool, not a runtime class).

BlockDialog interface (extends TransientObject)

Full member list confirmed: addAdditionalUpdateHandler, addApplyHandler, addCancelHandler, addCloseHandler, addDialogShownHandler, addEnableOKButtonHandler, addFilterHandler, addFocusNotifyHandler, addInitializeHandler, addKeyboardFocusNotifyHandler, addOkHandler, addUpdateHandler, getBlockProperties(String), launch(), launchInDialogMode(BlockDialog.DialogMode), performApply(), registerUserDefinedUIBlock, topBlock().

• launch() — "Shows the dialog in BlockDialog.DialogMode.CREATE mode."
• launchInDialogMode(dialogMode) — "Shows the dialog based upon the mode specified in BlockDialog.DialogMode. This method will not return until the dialog is closed, which typically is when the dialog's OK or Cancel button is pressed." Returns 1/2/3 for Back/Cancel/Ok-Apply.
• BlockDialog.DialogMode is only Create vs Edit (edit an existing feature vs. create new) — nothing to do with window hosting/docking. This is the only "mode" enum on the dialog launch path.
• Full-text search of the entire BlockDialog reference page (10,667 chars) for hwnd, window handle, parent window, dock, embed, reparent, resource bar, getwindow — zero matches.

Tree interface (extends UIBlock) — the Part-Navigator-style control

47,779 chars of reference content (full method/nested-type list: column sort/insert/edit options, drag/drop callbacks, label-edit callbacks, node insert options, etc.) Full-text search for dockpolicy, dock policy, hwnd, window handle, parent window, embed, reparent, resource bar, getwindow — zero matches. DockPolicy (the property we found in the Block UI Styler design-time property table, currently only observed set to "Allow Resize") does not appear anywhere in the Tree class's actual runtime API — it is read/written only generically via UIBlock.getProperties() → PropertyList, not as a first-class typed member with a documented enum.

UIBlock interface (base type for every Block Styler control, incl. Tree)

Only 6,147 chars total — this is the entire shared surface every block (Button, Tree, Table, ListBox, ScrolledWindow, TabControl, Wizard, etc.) exposes: enable() / setEnable(bool), expanded(), focus(), getProperties() → generic PropertyList, name(). That's it. No GetWindowHandle, no SetParent, no Dock, no Reparent, nothing window-system-related at all. This is the strongest evidence available: the base class every Block Styler widget inherits from has no capability to expose or move its underlying window.

Cross-checked Programmer's Guide pages that use the word "embed"

• NX Open Programmer's Guide > User Interactions > UI Styler (genid_ui_styler_56_12500) — the only page that literally says "embed a UI styler dialog in an interactive application," but "embed" here means wire the dialog's selection/filter callbacks into your automation code, not reparent its window. No mention of hwnd/dock/resource bar/reparent anywhere in its 12,662 chars.
• NX Open Programmer's Guide > User Interactions > Microsoft Windows Forms (genid_microsoft_windows_forms_27_1118) — covers only .Show() (modeless) vs .ShowDialog() (modal) for WinForms dialogs called from .NET automation; nothing about docking/hosting inside NX's own resource bar.
• Support Center doc "Embed WinForm-based dialog boxes in a journal" (PL20220512394070742.recording_nx_sessions / tools_jrn_prgex_forms_ht) — "embed" here means calling MessageBox.Show(...) and a custom NXOpenUI text-input class from journal code. Nothing about window hosting either.
• Site-wide search for the literal string DockPolicy across all of support.sw.siemens.com's indexed NX documentation returns zero results — it is not documented anywhere except implicitly in the Block UI Styler design-time property grid (already captured in blockstyler-tree-list.md).

Conclusion for the embedding question

Siemens does not document any DockPolicy value, API, or class member (across the Programmer's Guide, the Reference Guide, or general Support Center KB) that lets a Block UI Styler dialog — or its Tree/Node control specifically — be hosted inside a caller-supplied window or a custom ResourceBarManager tab. The only two officially supported presentation modes for a Block UI Styler dialog are:

1. BlockDialog.launch() / launchInDialogMode(DialogMode.CREATE|EDIT) — opens NX's own dialog window (floating or docked to the dialog rail, NX's choice, not the developer's), blocking until closed.
2. Building your own UI entirely (Qt in C++, WinForms in .NET via Form.Show()/ShowDialog()) and hosting that window's HWND inside a ResourceBarManager tab via GetWindowHandle() — which is exactly what ArchitectureTab.cpp already does with its hand-built QTreeWidget.

There is no third, hybrid path (reparenting NX's native Tree widget into an arbitrary host) documented anywhere in the official NX Open docs.

Relevance to spine-panel-kit / ArchitectureTab.cpp

This closes the open question from blockstyler-tree-list.md and INDEX.md's "Open threads" section: the native Part-Navigator-style NXOpen.BlockStyler.Tree cannot be embedded into ArchitectureTab.cpp's resource-bar tab via any documented API. The hand-rolled QTreeWidget + QSS approach (branch glyphs, gray highlight, gridlines) remains the only supported way to get a tree that lives inside our own custom resource-bar tab — there is no shortcut via Block Styler's native tree. Any further pursuit of "native tree in a custom tab" would require either (a) undocumented/reverse-engineered Win32 window-class + SetParent tricks against NX's internal dialog HWND (unsupported, fragile across NX versions, not something to build on), or (b) filing a Siemens GTAC feature request. Recommendation: treat the Qt/QSS styling layer in ArchitectureTab.cpp as final, and put effort instead into closer visual fidelity (e.g. the still-broken column header row tracked in the nx-tc-managed-connection memory record) rather than chasing native-widget reuse further.