Leaderboard

SVG is the way to go. There is a mountain of open source SVG rendering code that was built to make modern browsers SVG compatible. The thing to do would be to create a custom SVG-based format for all LabVIEW controls/indicators, and publish the specification. That way anyone who wants to would be able to create their own front panel object design libraries. Users could create their own designs and look for any application. I mentioned this over a decade ago in my Websocket post. They could also integrate the connector pane into the diagram as a boundary with multiple frames and tools for creating connector terminals. Unlimited sprawl on the diagram would be replaced with "main structure" whose boundary is the connector pane. Users would create paginated code within the boundary, with the separate pages executing in parallel. This would be an option rather than a rule. There would still be a traditional connector pane, but it would go with the diagram rather than the front panel. The relationship between front panel objects and diagram terminals would be user-configurable (Diagram files would be configurable to point to one or more front panel files, with the front panel objects therein becoming available to be included in the diagram, at the user's discretion).

I disagree. Large amounts of my code online have never required my support. It's happened with me several times. I don't like speaking in these absolutes. These half finished projects have been extremely valuable to me over the years, way more valuable then having nothing. Often times I will take the code, polish it, add features, then post it online. Not as perfect but so someone else could add to it if they ever wanted. A community that only shares perfect code shares nothing.

Not a huge leap but an improvement on events (IMO) would be Named events (ala named queues). Events that can be named but (perhaps more importantly) can work across applications in a similar way that Windows messages can be hooked from an application-all driven from the Event structure. I initially experimented with a similar technology when VIM's where first discovered (although it didn't work across applications). Unfortunately, they broke the downstream polymorphism and made it all very manual with the Type Specialization Structure - so I dropped it. Another is callbacks in the Event Structure. Similar to the Panel Close event, they would have an out that can be described. But getting on to the LabVIEW GUI. That needs to go completely in its current form. It's inferior to all other WISIWIG languages because we cannot (reliably) create new controls or modify existing ones' behaviour. They gave us the 1/2 way house of XControls but that was awful, buggy and slow. What we need is to be able to describe controls in some form of mark-up so we can import to make native controls and indicators. Bonus points if we can start with an existing control and add or override functionality. All other WISIWIG languages allow the creation of controls/indicators. This would open up a whole new industry segment of control packs for LabVIEW like there is for the other languages and we wouldn't have to wait until NI decide to release a new widget set. At the very least allow us to leverage other GUI libraries (e.g. imgui or WXWidgets).

As a workaround, what about using the .NET control's own events? Mouse Event over .NET Controls.vi MouseDown CB.vi MouseMove CB.vi