A web component inside a LabVIEW application
The aim is to choose the right tool for a specific part of the interface. LabVIEW retains the application logic; the web component handles its display and interactions.
JavaScript commands and messages connect the two. The application can change state or request information; the component reports a click, a playback change, or an error. This boundary lets the display evolve while keeping business logic in the application.
A fully programmable button
The demonstration shows an HTML button controlled through a LabVIEW API: text, icons, dimensions, colors, and typography can change at runtime. Interactions return to the application as events.
The button then becomes a reusable component in the containers of our DQMH interface framework. Multiple instances can form a menu bar with a presentation tailored to the product.
- Adapt labels, icons, and colors to the available actions.
- Control active, disabled, or toggled states from LabVIEW.
- Receive click and hover events for the application to process.
Control a media player with Video.js
In our Video.js work, a JavaScript API connects the embedded player to the LabVIEW module: media selection, play, pause, position, volume, and status reporting. The new demonstration shows the player in the API Tester, playback, status feedback, and customization of visible controls. The work also covers elements overlaid on the video.
Integration includes managing events and their frequency, as well as coordinating fullscreen behavior with the host window. Playlists require their own logic; gapless transitions between tracks should not be assumed.
Embed visualizations with Butterchurn
The supplied Butterchurn demonstration shows an animated WebGL visualization in a panel embedded in LabVIEW. The API Tester exposes initialization, preset selection, and sample-sending controls; the window can be resized while running.
This integration lets the native application control JavaScript rendering. The choice of effects and input data depends on the intended experience; synchronization and performance are verified in the context of the product.
Prepare a component that fits the product
We define the commands, events, and errors the component exposes. We check startup, resizing, keyboard focus, shutdown, and behavior while content is not ready.
The WebView2 runtime, web resources, and their versions are also part of delivery. Permitted content and available commands are scoped to the application’s needs. An initial representative component lets us validate the approach before extending it.