Multi-threading the UI

[chops88]

I'm trying to use the 3rd party Offline Maps plugin in my main UI - but it's quite laggy and bogs down the whole State machine. So, I ran it in a separate loop under the main state machine loop and changed the execution to "Standard" so that both while loops get their own thread. This improves performance, but I have to wrap my head around starting/stopping/restarting this 2nd loop. Should I use a queue for this and build a state machine for the 2nd loop or is there a more efficient way? Maybe I'm over-complicating the whole thing?

I wouldn't mind having it as another separately-called VI, as I have a number of them (mostly-headless) that the master UI launches and communicates with via queues, but then the map UI elements aren't in the same VI window. 

[Niatross]

From your description a seperate loop and a queue is the way to go.

Certainly don't have any code which takes a long time to execute in your loop with your event structure. This will cause blocking behaviour of your UI and is how I suspect you had designed it to begin with.

A good design would be to have your event structure waiting for any user events which are then handled by a separate loop, information (Like what event has been occured) should be communicated with a queue. This means your UI won't totally freeze whilst code executes, although if the code relating to one event does take an inordinate amount of time to execute it will prevent other events being handled.

If this is the case have a seperate loop for your inordinately long code.

This obviously doesn't scale overly well, but to give more advice we would really need to see what code you have done so far and a slightly more detailed description of what you are doing with this map. Actual VI's please rather than pictures. It sounds like there may be a lot of dependencies in your code so zip them all up and post everything...or even better simplified version of what you are trying to do.

[Niatross]

Also, personally I would steer clear of playing with execution priority. It has never solved any of my problems, and even if it did I suspect it would be a treatment of the symptoms of a more fundamental problem which should be addressed instead

[tst · Accepted solution]

---

@chops88 wrote:

I wouldn't mind having it as another separately-called VI, as I have a number of them (mostly-headless) that the master UI launches and communicates with via queues, but then the map UI elements aren't in the same VI window. 

---

Ignoring the questions of performance or configurations, you can insert VIs into subpanels, which do make them be part of the same window. Presumably your map control is a .NET control, which is slightly trickier, because those are drawn as their own window, but for most cases the implications from that are probably not relevant.

[chops88]

I had one event structure in the main loop, and another in the map loop. But I just wasn't aware of SubPanels before so I think that's probably going to solve the problem entirely - let alone having the ugly mess of 2 fairly complex state machines stacked on top of each other in the diagram.

On a side note, since starting with Labview a few years ago I've gotten a lot better at other languages in the meantime and I gotta say, sometimes its really nice to see the code in front of you visually, but debugging on a remote target is painful, and my god wiring is really tedious. I'd love it if there was some AI in the backend that reviewed common design patterns, your design history and suggested things intelligently. I do use Ctrl-Space lots, but some thoughtful help would be a little easier than rt-click, 7 context menus, place, wire, wire, wire, wire, wire, wire, s*** I mis-wired, unwire.... clean up wires,  wire. wire wire...  lol These are the times I miss the keyboard as the primary input method. 

Appreciate the offer to look at the design - not sure I'm allowed to pass anything along for IP reasons, etc.

[tst]

For commonly used things, there are a number of options you could go for:

1. Simple reuse code. These could simply be VIs which are installed in a standard place and are called from there. This could either be a shared location or a specific location in each project folder. Package managers like VIPM or GPM can help with managing the installation of those. The main con with these is that if you're writing the reuse code, you also have to manage that somewhere, including dependencies and the like.
   Here you can also use code developed by others. Since you were talking specifically about communication between processes, you could with something like the actor framework (in LV since ~2013) or the messenger library which you can find in VIPM or any number of others, which do some of the work in launching, communicating and stopping processes.
2. Dropping the content of a template VI directly in your code (search for "place VI contents").
3. Creating VI templates or project templates to launch from the new VI/new project dialog. There should be details in the help.
4. Writing plugins (for Quick Drop or the context menus) with scripting code to modify existing code to do what you want. If you think all that mouse action is tedious, just wait until you have to describe what to do in code. The advantage is that once you do, the tedious actions are done automatically. Similarly to the previous options, there are plugins for both frameworks both shipping with LV and available online.

[JÞB]

You know,  I boasted once that it took me over a year to miss a semicolon after switching to LabVIEW!  

Of course,  I still can't drive a sideways mouse but, my right-click finger is REALLY strong!

If you splurted your coffee on your keyboard reading this ....you got it!