Troubleshoot grid views

Grid views in the Syside VS Code Extension surface problems in the SysMLv2 Views panel when no view can be shown at all, and in banners inside an open view.

For issues not specific to grid views, such as installation, licensing, or a hidden panel, see the general Troubleshooting guide. It also explains what to include in a support report.

Panel issues

The panel shows no views

If the panel shows SysMLv2 Views require a Syside license, no license is active: see Activate license.

If the panel shows Views are unavailable because the Syside server providing them is not running, the language server is starting or has crashed:

  1. Wait a moment, then use the Retry button.

  2. If the problem persists, check the Syside output channel for errors and report them as described in Help us help you.

If the panel shows No views found in the model, no view usage in the workspace is typed by a SysideViews view definition:

  1. If the message offers Add SysideViews.sysml or Update SysideViews.sysml, accept the offer. The library file is missing or out of date.

  2. Re-check the view definitions against Table view structure or Matrix view structure.

The panel lists the views once the library is in place and the views are typed by its view definitions.

“The views are disabled because the SysML model contains errors or warnings”

The model has a syntax error, or the workspace holds two copies of the SysideViews library. Either way the views cannot be listed safely: a file with a syntax error is only partly read, so a view over it could be silently incomplete. Other errors and warnings do not disable the panel. They show in the views themselves (see A view shows a “Model errors” banner and cannot be edited).

  1. Read the list under the panel message. Clicking an entry opens its location.

  2. Fix each syntax error, or remove the second copy of SysideViews.sysml.

The views reappear in the panel once the model reads cleanly.

A view shows a “Model errors” banner and cannot be edited

The model has errors, such as an unresolved reference. The view still renders, but read-only, and it may be missing rows the errors affect. Warnings show in a yellow “Model warnings” banner instead, and leave the view editable.

  1. Open the errors listed in the banner, or in the Problems panel.

  2. Fix each one.

The banner disappears and editing comes back once the model has no errors. An edit is still refused if saving it would add a new diagnostic to the model.

View content issues

A table or matrix is empty

  1. Check the expose scope for typos. A qualified name that resolves to nothing produces an empty view, not an error.

  2. Check the default exclusions: reference and abstract elements are excluded until the corresponding include flag is set, and standard-library elements are always excluded.

  3. If elements are missing below a recursive expose X::**, check what sits above them: a reference or abstract element hides everything below it, not only itself (see Include flags in grid views).

  4. For matrices, read the per-axis warnings, such as Matrix has no rows. Check the rowView’s `expose` and `filter` clauses. Each axis is an independent selection, so fix the named sub-view.

The view fills in as soon as its definition is saved with the corrected selection.

A matrix opened as read-only

  1. Read the warning banner. It names the cause.

  2. If the banner says the cellView filter admits more than one kind of relationship, narrow it to one, naming both the kind and whether it is a usage or a definition. The derivation metadata alone admits two kinds: add the usage or definition half (see Make a matrix editable).

  3. If the filter admits none of the kinds a matrix can write, use one of the filters listed in Relationship kinds. Flow, binding and succession connectors are never written.

  4. If the banner says the cellView must expose one element, or that new definitions would not be shown or cannot be written, fix the cellView expose as in Point the cell view at where relationships go.

  5. If the banner lists model errors, see A view shows a “Model errors” banner and cannot be edited.

Once the cause is fixed, the banner disappears and right-clicking an empty cell offers Add Traceability.

A column shows an error, not values

Column `…`: … in a banner above the table means the column’s navigation chain is invalid. The message names the offending step and the rule it broke. The column degrades to empty read-only cells, and the rest of the view keeps working.

  1. Find the named column view in the SysML source.

  2. Apply the remedy in the message. Navigation step reference covers what a chain may contain.

Representation parameters never produce this banner: a languageName that matches no textual body degrades the column to its read-only defaultValue cells instead.

The whole table is disabled

`…` and `…` fan out in parallel, but a table’s fan-outs must form a single chain. Two anchors fan out in parallel. Rows are a property of the table as a whole, so this is the one chain error that disables the whole table instead of degrading a single column.

Follow the remedy in the message: reuse one anchor for both columns, or chain the second anchor through the first. The table renders again once its fan-outs form a single chain.

A hierarchical table reports an error or renders empty

A hierarchical table takes one expose, and its filter and flags judge every row, top rows included (see Hierarchical table view specifics).

  1. If the error names several exposes, keep one. To show several trees, declare a definition with a part typed by each and expose its members, as in Build a hierarchical table view.

  2. If the view is empty and a banner names its top rows, the filter or a flag removed them, and everything beneath them went too. Admit the top row’s kind in the filter, for example PartDefinition under expose Vehicle::**, or expose Vehicle::*::** so that Vehicle is not a row.

  3. If the view is empty and a banner names a package, the expose names a package with ::**. A package has no features to walk. Expose Pkg::*::** instead, or the definition at the top of the tree.

The tree renders once the view has one expose and its top rows pass the filter and flags.

Editing issues

Creating or editing is disabled

  1. If Add Traceability is disabled for a row or column, hover the warning on its header and see why a row or column is disabled.

  2. If editing is disabled for some rows of a hierarchical table, the row’s element appears more than once in the tree, so an edit would change every occurrence. Edit it in the definition that declares it. See Hierarchical tables.

  3. If Add Requirement is grayed out, the view’s filter clauses do not admit requirement elements, or the model cannot currently be written to: it has errors, source files hold unsaved edits, or another write is still in flight. See Create requirements.

Once the cause is fixed, the action is enabled again and its warning no longer shows.

Warnings about relationships

  • N cell(s) represent multiple traceability connections… More than one relationship exists between the same pair of elements, and the warning details list each one. This is informational, not an error.

  • N derivation connection(s) have non-Requirement endpoint(s)… A derivation relationship connects elements that are not RequirementUsage or RequirementDefinition. Fix the relationship endpoints in the model.

Library issues

“Workspace SysideViews.sysml is out of date”

The workspace copy of the library differs from the one it should match: the library bundled with the extension, or the 0.11 library in compatibility mode.

  1. Click Overwrite with bundled version in the banner, or run Syside: Update SysideViews.sysml from bundled copy from the Command Palette. In compatibility mode this restores the 0.11 library, so the views keep working as before. Moving to the 1.0 library is a separate step, covered in Migrate grid views.

  2. Avoid editing SysideViews.sysml by hand. Updating replaces the file.

If the copy comes from an installed Sysand package or from a file outside the workspace, the overwrite is refused. Update the library where it is maintained.

The banner disappears once the workspace copy matches that library.

“This workspace’s views are written for SysideViews library 0.11”

The workspace’s views were written for Syside 0.11 and run in compatibility mode. They render as they did in 0.11 and stay editable unless the model has errors. Support for compatibility mode will eventually be discontinued.

  1. Follow Migrate grid views. After its preparation steps, it has you click Update the SysideViews library to 1.0… in the banner, then moves each view to the 1.0 notation.

The banner no longer appears once the workspace uses the 1.0 library.

“This workspace’s views are written for a pre-0.11 version of Syside”

The views were written for a version before Syside 0.11, which Syside 1.0 cannot read or migrate. Syside 1.0 shows an error instead of the views, and offers no fix in the panel.

  1. Open the workspace in a Syside 0.11 extension and migrate the views to 0.11 there.

  2. Reopen the workspace in Syside 1.0. The views then run in compatibility mode (see “This workspace’s views are written for SysideViews library 0.11”).