Implemented Data Editor Message Registry

[stricklandrbls]

Closes #1739
Closes #1659
Closes #1469
Closes #1058
Closes #669

Description

• Implemented a Message Registry which provides type-safe message content inspection for messages sent between the data editor, dfdl extension, and the Svelte UI.
• Restructured some legacy Svelte stores into Svelte v5 runes.
• Resolved issues related to message content mismathcing and message content being processed by multiple data editors when the message was intended for a single data editor instance.

Wiki

• I have determined that no documentation updates are needed for these changes
• I have added the following documentation for these changes

Review Instructions including Screenshots

Developer Perspective Reviews

1. In any portion of the data editor's extension source, verify that message content is appropriately inspected and the VSCode intellisense engine emits correct types when invoking this.panel.postMessage(...).

Screenshots ( dataEditorClient.ts -> 'fileInfo')

2. In any portion of the data editor's Svelte UI source, verify that message content is appropriately inspected and the VSCode intellisense engine emits correct types when invoking addListener(...).

Screenshots ( DataEditorLineFeed.svelte -> 'viewportRefresh')

3. In any portion of the data editor's Svelte UI source, verify that message content is appropriately inspected and the VSCode intellisense engine emits correct types when invoking vscode.postMessage(...).

Screenshots ( App.svelte -> 'requestEditedData')

---

Functionality Review

Verify that all message traffic behaves as expected. Message content can be identified within the ./src/ext_types/message.ts & ./src/ext_types/messageContent.ts

[stricklandrbls]

Looks like I'll have to fix tests due to the strict type checks when transpiling with yarn tsc

[stricklandrbls]

@scholarsmate Is the omegaEditServerLifecycle.ts a test file? The CI jobs are failing due to a permission denied when trying to run the transpiled JS file.

Disregard, I fixed this issue.

[stricklandrbls]

Some changes needed to be made in order to get the updated data editor files to function properly for CI. Everything should be good to go, now.

[hdalsania]

@stricklandrbls Is this PR ready to test?

[stricklandrbls]

The svelte imports should now all be aliased if the path is not a sub-directory of its path.

The rest of the extension imports still need to be updated.

[lrbarber]

@stricklandrbls , I did some testing on this code and found that the data editor does not open automatically when starting debug. Wondering if some messages are missing? The status bar at the bottom shows no indication that it is even trying to connect to the server.
Opening the data editor manually works, but it does not get the location tracking indicator. Also, after closing the editor and restarting debug, attempting to open data editor again results in an error: A Data Editor already exists for .

[stricklandrbls]

@stricklandrbls , I did some testing on this code and found that the data editor does not open automatically when starting debug. Wondering if some messages are missing? The status bar at the bottom shows no indication that it is even trying to connect to the server.

Opening the data editor manually works, but it does not get the location tracking indicator. Also, after closing the editor and restarting debug, attempting to open data editor again results in an error: A Data Editor already exists for .

Awesome thanks for testing this. I'll take a look

[stricklandrbls]

@lrbarber The latest commit should fix the issue of the Data Editor not opening for the target data file in a debug session.

[lrbarber]

Tested Data Editor functionality thoroughly (including Profiler) and really only found one issue.
I was debugging as normal then opened a second data editor window with a different file. Everything was working fine. I closed the second window and then again tried to open a second window with the same file. It seems that closing the data editor window failed to clear in the file tracking, because it seemed to think that file was still open in a window.

[lrbarber]

See comment above about closing then reopening a second file

[stricklandrbls]

See comment above about closing then reopening a second file

Awesome thanks for the thorough testing. I'll work on a fix for this

[stricklandrbls]

@lrbarber @hdalsania @scholarsmate - Sorry for the delay in getting updates out for this PR. I have been out of town a lot recently.

I believe that the error is fixed for sessions opened for a file that should be disposed.

[lrbarber]

With two files opened in the data editor, I opened the Profiler on both of them.

They both defaulted to the same length even though the files were not the same size (or actually that big). It also appears that it does not actually look at the data and fill the graph until you change the start or end offset values. Didn't this default to the entire file?
If you change the start offset, leaving the end/length set to the default (and invalid length) the following error messages occur:

Expanded window show the rest of the error message:

Also, comparing the end offset and the length... if I start the selection at 0x00 for a length of x, shouldn't the end offset be x-1? ...or is the end offset included in the length? start 0x00, len 0x10, last byte included is 0x0f -- so what should be displayed for end offset? Now think about start 0x00, len 0x01, end offset ??

In the file below, I placed 0xFF at 0x11. The graph shows that there is an 0xFF in the selected data, but there shouldn't be, because I entered length 0x10

[stricklandrbls]

@lrbarber thanks for testing this out. I'll take a look here in a bit

[stricklandrbls]

@lrbarber - I pushed up a commit which I think completely resolves this error.

I did in fact see what you were seeing and with the latest commit it seems to be resolved.

[lrbarber]

@stricklandrbls Something strange with the profiler.

Notice that the first 0xff is located at location 0x20.
When I profile the first few bytes everything looks OK.

...but when I add the 6th byte, it suddenly thinks there is an 0xff within the selected range!

Scrolling down reveals inconsistency in field size:

Also, all the numbers here are in hex, except when you hover over a bar in the bar chart, then the value at that location is shown in decimal.... byte: 256 frequency: 1

[lrbarber]

@stricklandrbls After closing a data editor window (without closing the second VSCode wndow), the following messages begin scrolling in the Debug Console of the 'main' VSCode window:

rejected promise not handled within 1 second: Error: Webview is disposed
stack trace: Error: Webview is disposed
at uN.assertNotDisposed (file:///c:/Program%20Files/Microsoft%20VS%20Code/6a44c352bd/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:669:112635)
at get webview (file:///c:/Program%20Files/Microsoft%20VS%20Code/6a44c352bd/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:669:111596)
at SvelteUIWebviewPanel.postMessage (c:\Users\larry.barber\Documents\testing\daffodil-vscode\dist\ext\extension.js:22008:27)
at DataEditorClient.sendHeartbeat (c:\Users\larry.barber\Documents\testing\daffodil-vscode\dist\ext\extension.js:22414:38)
at Timeout._onTimeout (c:\Users\larry.barber\Documents\testing\daffodil-vscode\dist\ext\extension.js:22312:10)
at listOnTimeout (node:internal/timers:605:17)
at process.processTimers (node:internal/timers:541:7)

[stricklandrbls]

@lrbarber - I believe these issues should be resolved with the latest commit