Adam Kemp

It's actually CAR# 526291.

Right, but my previous post explained how you can create a LabVIEW application on Linux that does not have a dependency on X11 at all. That method is officially supported, and it was designed for exactly this use case. It is what we (NI) recommend doing.

For what purpose?

Does it work for other commands, or do they all fail the same way? As I'm sure you're aware LabVIEW normally doesn't want to create new instances of itself so you would have to give it an argument (that I can never remember) to create a new instance. I'm honestly not sure why that would cause this VI to fail (as opposed to just appearing to do nothing), but I thought it was worth pointing out. I also noticed there are quotes in the command line. Is that expected? It's been a while since I've used this VI so I can't remember whether those are necessary or forbidden.

You can build a Shared Library in LabVIEW for Linux with the "Embedded" runtime (in the Advanced page of the build spec properties check the box that says "Use embedded version of run-time engine"). When you do this your shared library will link against a LabVIEW runtime engine without GUI support, which means it does not require X windows. We don't support building executables this way, but you can build a shared library and then load it into a simple shell executable written in another language. This may be a useful way to write your server. As for system requirements in general, our website documents that information: http://sine.ni.com/nips/cds/view/p/lang/en/nid/2541 (see the "overview" tab).

The communication for -launch goes through the X server and uses string names so if there is another LabVIEW process running on the same X server the message will go to it regardless of which machine it was run from. That's just a result of how we communicate with our already running process. If you just want to send messages to an already running application then you can use some other method of inter-process communication like named pipes or TCP. This is probably what LabVIEW should have done as well, but alas that's not how we implemented it.

Howdy! I'm glad to see you're trying out the app. When you browse for variables in Data Dashboard it will only show variables which are supported. The list of supported types is here: http://digital.ni.com/public.nsf/allkb/D9B247551BE7F46A8625795000552CDE?OpenDocument There's also a troubleshooting page with useful links here: https://decibel.ni.com/content/docs/DOC-19388 Lastly, keep in mind that the application does not support authentication. If you need to secure your variables then we suggest using VPN. If you go through the documents above and still can't figure out what's wrong then please visit our official support forum for this product here: http://forums.ni.com/t5/LabVIEW-Web-UI-Builder-and-Data/bd-p/480

I'm excited to finally be able to tell you all about the project I've been working on since NIWeek. Thanks to the success of the iPad in the last two years tablets have become very common. They're more convenient in many cases than laptops, and an increasing number of people are carrying iPads or other tablets around instead of a full blown computer. You can do a lot of things with a tablet, but there are still some gaps, and access to your LabVIEW applications has been one of those gaps until now. Data Dashboard for LabVIEW is a FREE tablet application which gives you a simple, intuitive interface to quickly connect to and display data from a network published shared variable and/or LabVIEW web service. If your application publishes useful data through either of those mechanisms then you can show it on a tablet from anywhere. Data Dashboard supports scalar integer and floating point numeric, boolean, and string data types and four controls: text, chart, gauge, and LED. You can connect to up to 6 variables/web services at a time on a single page, and you can have multiple pages to connect to different sets of data. Data Dashboard is available in the iOS app store (for iPad only) and the Android Market (for Android 2.3+ tablets, not phones). Also coming soon to the Amazon App Store. You can read more about the application here: https://decibel.ni.c.../docs/DOC-19387 Please give it a try and let me know what you think.

I don't know what you mean by this. Can you show me the C code which is giving an error (I assume you probably mean crashing?). If you have an array of clusters of two strings then your data will look something like this in C (I assume you are including extcode.h, which comes with LabVIEW in the cintools directory): typedef struct { LStrHandle str1; LStrHandle str2;} ClusterWithTwoStrings;typedef struct { int32 cnt; ClusterWithTwoStrings elt[1];} ArrayOfClustersWithTwoStrings; Then your C function would look like this (assuming you set it up to be "adapt to type" and "handles by value"): void MyFunction(ArrayOfClustersWithTwoStrings** arrayHandle){ if(arrayHandle) { for(int32 i=0; i != (*arrayHandle)->cnt; ++i) { if((*arrayHandle)->elt[i].str1) ; // do something with this string if((*arrayHandle)->elt[i].str2) ; // do something with this string } }} Note the checks to make sure the array handle and the string handles are not NULL. In LabVIEW an empty array is a NULL handle, and an empty string is a NULL handle as well. You may be crashing because you are not checking for empty. So let's assume now that you want to actually create this array in your C code. That's a little more complicated. What you have to do now is pass in a pointer to the handle (just in case it's empty you need to allocate it and give it back to LabVIEW), so you set your call library up to be "adapt to type" and "pointers to handles". Now your C function looks something like this: void MyFunction(ArrayOfClustersWithTwoStrings*** arrayHandlePtr){ if(arrayHandlePtr) { if(*arrayHandlePtr) { // free any existing elements for(int32 i=0; i != (**arrayHandlePtr)->cnt; ++i) { DSDisposeHandle((**arrayHandlePtr)->elt[i].str1); // This function can handle NULL without an error DSDisposeHandle((**arrayHandlePtr)->elt[i].str2); (**arrayHandlePtr)->elt[i].str1 = NULL; (**arrayHandlePtr)->elt[i].str1 = NULL; } // Resize the array and clear any new elements DSSetHSzClr(*arrayHandlePtr, Offset(ArrayOfClustersWithTwoStrings, elt) + sizeof(ClusterWithTwoStrings)*numberOfElementsToAllocate); } else { // Allocate a new handle *arrayHandlePtr = (ArrayOfClustersWithTwoStrings**)DSNewHandle(Offset(ArrayOfClustersWithTwoStrings, elt) + sizeof(ClusterWithTwoStrings)*numberOfElementsToAllocate); } if(*arrayHandlePtr) { (**arrayHandlePtr)->cnt = numberOfElementsToAllocate; // Initialize new elements } else ; // error } else ; // error} (sorry about the tabbing; I can't figure out what this editor wants...) The important things to note here are: Arrays and strings must be allocated (or resized) using the LabVIEW memory manager functions (DSNewHandle, DSDisposeHandle, DSSetHandleSize, DSSetHSzClr, etc.) from extcode.h. Link against labviewv.lib to get access to those functions. Empty arrays or strings are NULL. After disposing a handle set it to NULL After allocating or resizing a handle for an array or string set the cnt field to the number of elements you allocated. When allocating space for an array or string you have to calculate the total number of bytes for that array or string. You do this by using Offset(structName, eltField) (to get the number of bytes for the cnt field plus any padding) plus the size of your element (ClusterWithTwoStrings for your cluster or uChar for a string) times the number of elements you want. Also note that you can convert an LStrHandle (a LabVIEW string) to a null-terminated C string using LToCStrN, and you can also convert from a C string to an LStrHandle using LStrPrintf. You can find documentation for these functions in the LabVIEW help. Also check out the "Calling Code Written in Text-Based Languages" section of the help. There's a lot of information in there.

The web services feature is not supported on Linux. You can only deploy the web service from a Windows machine and only deploy to a Windows or RT machine. If for some reason you need to do the configuration part from Linux then you may try the Moonlight plugin instead (http://www.mono-project.com/Moonlight). It is meant to be a replacement of Silverlight for Mac and Linux. I have no idea whether the configuration utility works in Moonlight, but it's worth a shot. I'm not sure if that's really useful to you, though, if you can't deploy from or to Linux anyway.

CAR #281328.

That least part is a contradiction, though. A "restore" is a resize. You can't say it's not resizable if you are able to "restore" it. That changes the window's size, therefore it is resizable. The fact that you can get into that state is a result of the fact that we treat non-running VIs differently. When you maximized the window it was resizable. It's a bug that when you run the VI and resizing is disabled we don't immediately unmaximize it. That's just a bug, though. What you described after you unmaximize is the correct behavior. You should not be able to do anything to a non-resizable window to change its size, including maximize or unmaximize, and as I said before, you can't have a "maximized" window which can't be unmaximized. Therefore maximized and non-resizable windows are a contradiction. This can't be done. As I said, that's a contradiction. You can't have a "maximized" window that is not resizable. It's just not allowed. The only way to disable minimizing unmaximizing is to disable resizing, and disabling resizing means you can't maximize to begin with. I have to ask, what value is the title bar if you can't minimize, unmaximize, etc.? Why do you want the title bar visible? If you hide that you can't move it. Problem solved. I think you're making it harder just to show a useless title bar. This is not a bug. It is the expected behavior. Not in teh way you have described. The presence of a title bar implies that you can move it. The ability to "maximize" (which in OS X means make larger, not necessarily fill the screen, and it doesn't ever disable resizing of any kind) implies that you can resize the window to begin with. This is the platform where that contradiction is most apparent because "maximize" is truly just a resize. It's equivalent to manually moving and stretching the window to fill the screen, thus is can't be done if you disable resizing. The only way to get a full-screen, non-resizable, non-movable window is to disable resizing, hide the title bar, and set the window size to be the full size of the screen.

That's true, but my point is that "resizable" applies to more than just whether or not there are resize handles. On OS X there is no such thing as "maximized" in the sense of not having borders. That concept just doesn't exist. Also, in Windows 7 you can grab a title bar from a maximized window and drag it somewhere else to unmaximize and then move it. There's no such thing as "maximized and not umaximizable", and If the size can change then it is resizable. Maximizing and unmaximizing changes the size, therefore if a window is maximizable it must be resizable. Like I said, this is just how it works. You can't be "maximized" if you're not resizable. The best you can do is try the steps I listed above.

Sure you can. Just unmaximize it. That's a resize. You can only be in a maximized state if your window is resizable because you can't get into a maximized state without maximizing, and maximizing is itself an act of resizing. That's just the way Windows and Linux (and presumably OS X) work, and at the very least that's the way LabVIEW works.

Maximized implies resizable. That's just how the window managers work. It sounds like what you want is something to be full screen. To do that you need a combination of multiple settings: disable resizing, hide the title bar (which appears to also hide the border), hide the toolbar (or not, maybe you want that), then set the panel bounds to be the size of the screen. Make sure to reset all of that when your VI is stopping or it could get quite annoying to work with. When I experimented with this it looked like maybe LabVIEW wasn't accounting for the invisible border when I set the panel bounds, so you may need to account for that. You also may want to hide the scrollbars while running (that can be set directly from the front panel).