Data Explorer menu has 3 options - 1 of which throws an error

[anna-poplawski]

When I open this menu with a sldd file open (I can't get a screenshot of the opened menu) there are 3 different Simulink Data Explorer options:
Data Explorer - Simulink Data Explorer
Data Explorer (editable) - Simulink Data Explorer
Data Explorer (editable) - Simulink Data Explorer

1 of the 2 Data Explorer (editable) options produces an error when I select it.
The other 2 options (Data Explorer and the other Data Explorer (editable)) both go to Data Explorer (editable)

[ww-mw]

Thanks @anna-poplawski — both halves of this reproduce, and they have different causes. One is fixed; the other is a naming decision I'd rather not make unilaterally.

Why there are three entries

All three are registered for *.sldd, and a custom editor's selector is a filename glob — but the two .sldd formats (JSON text and compressed-binary zip) are not distinguishable by name. So every .sldd is offered all three:

menu entry	viewType	what it is really for
Data Explorer	dataExplorer.binaryView	the default; reads the bytes and routes to one of the two below
Data Explorer (editable)	dataExplorer.tableView	a JSON dictionary, backed by a TextDocument
Data Explorer (editable)	dataExplorer.binarySlddView	a compressed-binary dictionary

That is also why the other two both landed you in the same place: for a JSON dictionary, the default view redirects to tableView, which is the same editor the second entry opens directly.

The error — fixed

BinarySlddEditorProvider.openCustomDocument called unzipSync unconditionally, so picking the binary editable view for a JSON dictionary threw before any panel existed:

Error: invalid zip data
  at unzipSync
  at BinarySlddEditorProvider.openCustomDocument

Fixed in #28 (shipping in 1.24.5): the unzip is guarded, and a non-zip .sldd is handed back to dataExplorer.binaryView, which owns the single format-to-editor rule. Picking that entry now simply lands you in the right editor instead of erroring. Pinned by a new integration test that drives the real provider in VS Code and asserts the tab you end up on.

The confusing menu — needs a decision, so I've left it open

Two entries still share the name Data Explorer (editable). And the mirror of your bug is still there in a milder form: picking the text-backed entry for a binary .sldd opens a tab VS Code cannot populate (File seems to be binary and cannot be opened as text). Our provider is never reached in that case, so unlike the fixed direction it cannot self-correct.

I measured one thing that determines what is possible here: vscode.openWith does honour an explicit viewType whose declared selector does not match the file. (Probe: openWith(model.slx, 'dataExplorer.binarySlddView') reached our own openCustomDocument.) So the editable viewTypes can be taken out of the menu without breaking the redirects that depend on them.

Three options:

(a) Remove both editable viewTypes from the menu — narrow their selectors to a glob that matches nothing, leaving one Data Explorer entry that always routes correctly. Cleanest: one entry, no wrong choice possible, and the redirects keep working (measured above). You lose the ability to force a specific editor, which nothing needs today. A selector matching nothing is a slightly odd thing to commit, so it wants a comment explaining itself.

(b) Give them distinct names — e.g. Data Explorer (JSON dictionary) / Data Explorer (binary dictionary). Cheap and honest, no behaviour change. But it surfaces a storage-format distinction most users neither know nor care about, and still lets them pick the one that cannot work.

(c) Leave it — now that the JSON direction no longer errors, the remaining cost is a confusing menu plus one combination that opens a dead tab.

I'd recommend (a): the menu should not offer a choice that can be wrong when the right one is derivable from the bytes. (b) is the fallback if being able to force an editor turns out to matter.

[ww-mw]

Fixed — the entry that errored was corrected in 1.24.5, and as of 1.24.7 a dictionary offers a single Data Explorer entry to pick; if one does still end up open in a view that cannot show it, it is now re-opened in the view that fits. Thanks for the report.