John Lokanis

Now we are getting off topic, but the reason to split the current system is because having the UI tied to the engine that executes the plugins means that for each instance, only one user at a time can access and control the machine. By splitting them, the client application can view sessions from multiple servers at the same time. And multiple clients can view sessions from the same server. I can have one server for everything or I can have N servers as demand increases. And I can have N clients using that same server pool. I can also have clients view sessions based on criteria besides what server they are executing one. With the current system, you can only see the sessions on the server you are viewing since the UI is hosted by the same application that executes the plugins. The best analogy I can think of is a web server and browser. The current system would be equivalent to having the web server and browser be a single EXE. To view the web page, you would have to log onto the machine running this exe and while you were using it, no one else could. So, to view a web page, you would need to give each user their own server/browser application. Also imagine that while the page is being viewed by one exe, it cannot be viewed by another at the same time. The new architecture separates these functions but the server still needs to serve up some UI information at run-time that the client cannot have prior knowledge of. Ideally I would prefer to have the flexibility of having the UI information be a fully functional VI. That way I am not limited in the future to what my prompts can look like or do. But, if that is impossible I might have to make a generic prompt and simply push configuration info from the server to the client. I have tried to keep the problem description generic because the point of the thread was to find a way to dynamically push a VI to another machine and run it. That seems like something that would have more applications than just my current design. So, not concerning yourself with my motivation, does anyone know a good way to send a VI (actually a hierarchy of VIs) from one LabVIEW EXE to another and execute it at run-time?

Unfortunately that is not an option for me. The client needs a lot of custom code. It needs to manage multiple servers at multiple sites, shared views and access control for multiple clients viewing the same server session, database recall of historical output, etc... The client is actually more complex than the server and has just as much parallelism if not more than the server. So, LabVIEW is a natural fit. I would need a whole team of Javascript devs to attempt to reproduce it. But thanks for the idea anyways.

I am trying to think this through and see if it is even possible. I can think of a few possible paths to go down but am not sure if either will work or if there is a better way. The goal: I have two application instances running on two different machines on the same network. I want a VI that is part of application instance A to be displayed and executed in a sub-panel of a running VI in application instance B Why? Well, I am splitting an existing application into two parts. A server and a client. The UI is hosted in the client running on app instance B. The Server is running on app instance A. The server executes a set of plugin modules. Some plugins require a custom prompt to be displayed to the user. In the old system (all on one app instance) I could pass the plugin a handle to the sub panel in the UI and it could insert it's prompt VI for the user to see and take an action. But now that they are split, I cannot do that anymore. The plugins are created outside of both the server and the client applications so they do not know what the prompt will be until run-time. Option 1. When I update the plugin libraries, I need to push a copy to both the server machines and all client machines (already this seems like a bad idea). Then, the server can simply tell the client what prompt to load, display and run. I would need a mechanism for the prompt to send its data back to the server plugin. And there would be a lot of unused files on the client side since it only needed the plugin prompt VIs and their sub vis. Option 2. When I need the client to display a prompt, the plugin would determine the local path to the prompt VI and to all of it's sub-vis (this is not too hard) and then it would load the binary data from disk for each of those VIs, send it over the network and on the client side, save it to a temp folder. The tricky part would be to re-name (using some temp pre/suffix) the destination files and re-link them together (no idea how to do this but I think it is possible). Then the plugin would tell the client where to find the prompt VI locally to load, display and run. I would again need the prompt to message the server with it's output once the user responds to it. This option, while complex, seems like the best way to go. Since it is similar to building a source distribution, I am hopeful there is a way to do this. I just don't know how. Option 3 I can't think of another option. Any ideas? Thanks for reading. This one has me a bit stumped. Oh, and all this needs to work under the run-time engine so no scripting allowed! -John

Good catch. Never type while mad. I should have done a better job proofreading.. (we really need a :facepalm: emoticon on LAVA)

I'm ok with that but will the Focus Row property be public?

Thanks! This definitely fixed my problem. Please let me know who to buy a for at NI Week. One note: If you try to write -1 to the Focus Row, you get an error. Writing -1 to the value deselects all rows so sometimes I use this to purposely not have a row highlighted. I had to add some code to detect this and not set the Focus Row property in those cases. Nice to see this will be in 2013. Are you saying that this will be publicly available or that the focus row will automatically be set to the value? While we are on the subject of fixing the MCLB, here is something I would like to see: Set the number of visible columns and the minimum width of each column. When scaling the control within a pane, widen or shrink the columns so the requested number of visible columns is maintained. Allow us to set the control to auto scale all columns or a specific subset (so some columns maintain their width while other scale). I can do all this in code, but there is so much lag in handling the re-size events that it inevitably is visible to the user as the columns adjust. This gets especially problematic when there are multiple MCLBs in multiple panes on a panel. Oh, and do the same for Trees as well! thanks again for the help! -John

Yup. Just dug up the code (had to go back to something I wrote in 2004 to find it) and I had ended up solving it the same way. That is one old bug. I wonder if it will ever get fixed...

This is driving me nuts! I have a VI with a MCLB display. When I open this VI, I select a particular row (for example, row 3) and set the key focus to the MCLB control so the user can use the arrow keys to navigate without first clicking on the control. This works fine the first time I open the VI in my application. If the user presses the down arrow, the selection moves to row 4 as expected. If the user navigates to a different row (for example, row 8) and then in the main program takes an action that causes my MCLB VI to be activated again (this time selecting row 5), I bring the MCLB VI to the front most and again set the key focus to the MCLB control. Row 5 is highlighted as expected. But if the user presses the down arrow again, the selection changes to row 9, not 6 as would be expected. Even though the control value is set to row 5 and row 5 is highlighted, somehow the control remembers that the last row navigated to manually was row 8 and it thinks it is still on row 8! I have tried setting the active cell to the selected row to see if that fixes it but with no luck. I have also tried changing the order of when I set the MCLB value and the key focus but that seems to have no effect. Even if I close the VI containing the MCLB and then reopen it, it still remembers the row navigated to and not the newly set one. The thing that is bugging me even more is I vaguely remember having this problem years ago and solving it (I think) but I cannot remember how. Has anyone solved this or have any ideas? thanks for any thought or comments you can offer. -John

Thanks for the tip! Didn't think to check that. The problem window in question still lets me shrink it too small but at least the panes are still there when I enlarge it again. Made a little helper set of VIs for this. Pane Size Control.zip

Resurrecting this thread to ask about a potential LabVIEW bug. When you have several panes on your VI that are set to scale while resizing, they will all happily shrink down to the point where controls inside them become obscured (hidden) due to the pane being too small. So far, my only way to avoid this is to set a minimum window size that prevents the window from getting too small for this to happen. Unfortunately I have come across a situation where I do not have control of this setting for a specific VI and therefor have to deal with the effect. The 'bug' I am concerned with is the fact that the shrunken panes do not enlarge as the VI grows again. So, once you have compressed them, they stay compressed permanently. It seems to me that they should return to their original size as space allows so the controls inside can again be accessed. Does anyone know a 'trick' to work around this? thanks, -John

The schedule is 'official' now. And they have moved a few sessions around since I first set mine up. But, I was able to fill all my slots with something and managed to fit in most of what I wanted to see. Unlike past years where all the best sessions were scheduled at the same time! Good luck!

in my case, the user name was useless. I had to use my email address and the temp password after the "/".

The web interface seems to be working fine now. And the app works too. You must use the forgot password tool to get an initial password, apparently, to get the app to work. I was able to book all my sessions. Not too bad this year. Got all my #1 choices and only had to skip a few #2s due to conflicts.

Anyone know if they are going to have the online session registration this year, and if so, when it goes live?

After a day of playing with the XTab control, I can say that is looks promising but is too buggy for real world use at this point. I hope the author continues to improve it. In the meantime, I would recommend you look elsewhere for a tab solution.

I appove of the thread jacking because it led me to some more interesting tools, but to get back on topic: I should have thought of #1. Thanks for pointing out the obvious and easy solution. #2 and #3 won't work once you have lost the scroll bars and have no splitters. I ended up doing a variation of #4 before I saw your reply. In the end all is well but I agree that the setting should be the default. It would have no effect on normal VIs until you set a control to scale. So, why not? I bet this is already on the idea exchange somewhere... Now to go off and redo all my code using that cool tab x-control!

FWIW, I was able to 'trick' my original VI into giving me my scroll bar back so I cold set this and it now works. Still need an easy way to get those scroll bars back and this still needs to be a VI Server setting! thanks everyone for the help!

Ok, your version works as expected on my machine. But there is no scroll bar on the Container.vi. How do you get it back to adjust the setting? If I create a VI, drop a sub-panel and then select 'fit to pane', the scroll bars seem to be gone for good. I must be missing something... (other than the scroll bars). Finally, why is this "Scale Objects While Resizing" setting not available via VI Server?

Yes. Just D/Led and tried it. Same version of LV too. I did try the Fit Control to Pane in the resize event. works even worse. Best performance I can get is to use one vertical splitter bar and have the sub panel resize to that. The resize event is also passed to the VI in the sub-panel and that is where I have my custom resize code that adjusts my list box column widths. Still a bit laggy if they move the window edge too fast but it does catch up when they stop.

Doh! Try this one: http://screencast.com/t/Nq9KVfgI

Thanks Jack, your example looks like what I want but I get very different behavior on my machine using your VIs. See my screencast: http://screencast.com/t/Nq9KVfgI

The problem is when trying to make the splitter zero pixels and place it at the extreme edge of the screen. You still get a gap of a few pixels. I have been able to eliminate one of the splitters but I am still stuck with having one. Here is what it looks like:

I have been trying to get the VI within a sub panel to re-size dynamically (while the users is actively performing a re-size). I have programmed the VI in the sub panel to do real time re-sizing but I cannot get the sub panel to re-size actively when the user re-sizes the front panel that owns the sub panel. Even if you set the 'Scale all objects on the front panel as the window re-sizes' VI property, the re-size does not happen until the user stops the re-size action. It will not do it dynamically. My solution was to create a vertical and horizontal splitter, then place my sub panel to the right and below the splitters. I could then get it to resize the sub panel as the user performs the resize action. The problem I am left with is I cannot completly hide the splitters. No matter what type of splitter I choose or what color I set it to or how narrow I try to make it, I still end up with a border on the top and left of the front panel a few pixels wide. My LabVIEW-fu and Google-fu has failed me on this one. Has anyone else solved this? thanks for any ideas! -John

My main goal was to come up with an automated way to document the relationships between an actor and all it's messages. This is a natural case for a node map. Also, it will uncover the connections from other actors that connect to an actor via it's messages. This mainly makes sense if you are using a messaging architecture where each message is a class and the only communication path between your independent processes is via these messages. This is not limited to the Actor Framework. (I use my own architecture that is much less limiting than AF) but the concept still applies. Applications written with this type of architecture can very quickly become too complex to understand, even for the author. By having a diagram like this, you can have a means of graphically representing the logical links within the system that are not visible in the source code, even when using a graphical programming language like LabVIEW. This is admittedly a very early version of this tool that I just put together in a few hours to prove the concept. I hope to improve on it over time but wanted to share the idea and code in case others wanted to contribute.

Yes. You get what you pay for! But, you certainly can automate the generation of the excel file so you can easily import the data and customize the graph in several ways. Not a bad compromise. There are other tools out there for creating node maps. Perhaps there is a better solution.