WMassey

Make sure that PC-related stuff isn't messing you up. Make sure the system isn't going into standby or some BIOS-driven power saving mode. Also make sure the DMM isn't going to do the same thing.

User the "Reorder" button on the toolbar.

I was taking screen shots of a running LabVIEW program and dumping them into a MS Word document today and at some point, in switching back to the LabVIEW from the MS Word, I realized that the open subVI window which I was looking for didn't show up in the WinXP taskbar list of open VI windows. After some investigation I figured out that the subVI in question is setup to programmatically disallow the "minimize window" option and that was what was keeping the window name off the taskbar list. I wouldn't exactly call this a bug because it sort of makes sense that a taskbar item wouldn't be needed to restore a window if the window couldn't be minimized. But the taskbar items can also be used to bring a window to the front and this ability is effectively denied to us in this situation given the way this was implemented. Call me greedy but I wish the choice had been left to me about whether or not hide the taskbar window name.

Ahh.. this is just what I needed. I did need to revise your top-level VI just a bit to get it to stop err'ing out on the vi's without block diagrams or those from vi.lib that were password protected but otherwise it worked like a champ! Thanks! FWIW, I've attached my modified version of your tool. Download File:post-2800-1137433536.zip

Well if you don't want to wait and do want to poll try using the "VISA Bytes at Serial Port" function to see when there are enough bytes waiting to be input to attempt a read. You could also setup another asynchronous process (or loop or state) whose job it would be to hang on the read until a complete response were available and then make that response (possibly with a timestamp) available (queue, global, LV2 global, ...) to the rest of your code before going back to wait again.

I agree that Khalid's answer may be what you really need to make your application work, but to answer the question as you posed it, to get your simple VI to output a 3-byte ASCII string then you need to use a %03d format string. FWIW, you used the the "Format Value" function found on the String -> String/Number Conversion palette. That (and most all of the other conversions on that palette) are somewhat outdated and have been replaced by the more universal "Format into String" function (and its complementary "Scan from String" function) found on the top-level String palette. One of the advantages of the "Format into String" function is that you can right-click on it and select the "Edit format string" option which will bring up a window which will lead you through the various options required to produce the type of output string you desire. For example, the foregoing %03d format string is built using: Format Decimal Integer + Right Justify + Pad with zeros + minimum width=3

It looks to me like you are getting the last portion of one message and the first portion of the next. How are you deciding when it is time to read the string? I assume that this is RS-232 communications and you are using the VISA serial-port VIs to setup & control the communications? Correct? Have you setup the VISA Configure Serial Port VI to terminate the read on the second one of your delimiters (possibly a linefeed character)? You can also set this up using a VISA property node before the read operation. See the attached example (LV v7.1.1). I just noticed that you have LV v6.1 so I have also attached a 6.1 version of the example in a zip file. If you are doing all this, then I have no idea why you are getting the results you are seeing. Download File:post-2800-1136554812.vi Download File:post-2800-1136555775.zip

If you actually want to control it while the VI is running then you will need to use a VI Toolbar Visibility property node. More info can be found here.

It works with labels. It works with text strings that just sit on the front panel. It just does not seem to work with Boolean Text. "Making value default" does not affect it.

I'm guessing the answer to this is No but I thought I'd ask anyway. I'd like to be able to mix a couple of "WingDing 2" font symbols (that very nearly match a couple of listbox symbols) in with the "application font" text used on a couple of boolean controls. The mixed fonts don't seem to survive when I close & re-open the VI. Is there a way to do this? (LV 7.1.1)

Sounds like someone needs a quick trip up to the Sierras. Just wait 'til summer gets here Michael... As Mark Twain said "The coldest winter I ever spent was one summer in San Francisco." Of course with the changing weather patterns around the globe who knows what the future will bring. Happy Holidays & pass the sun block!

This second method is a favorite of mine as well. I use the TypDef'd control to establish the structure I want and then use the subVI to provide the access to the constant and also to establish the default value for the constant. I've attached a small example of this taken from some work I have done. Very few changes to the example are required to allow for multiple enumerated constants, if that is desirable. Download File:post-2800-1135686401.vi

No, the abort button/function does not have an event associated with it. FWIW this same topic was discussed over here. I think that the best you are going to be able to do is to hide the abort button if you don't want the user using it. You can do that either through the VI setup properties or a VI property node. Keep in mind that, before you hide the function, your VI needs to be bulletproof in the way it operates because you won't have a good way of stopping it (other than the three-finger salute [Ctrl/Alt/Del]) if it misbehaves.

If you are indeed worrying about the file size getting too big, I'm not sure the worry is justified in this era of huge disk drives and disappearing interest in floppy disks. Yes, using the file zip tools of the OpenG package, you could decompress zipped VIs before they were called and delete the expanded file afterwards. If you have the application builder as part of your LabVIEW development system you could use it to strip the front panels from the VIs that didn't require them before they are saved to the LLB file. You can also minimize the amount of memory used by the front panels that are required by minimizing the number and complexity of the controls & indicators you use on the front panels.

According to Wendy from NI, this would seem to be a "feature" of LabVIEW. I'll need to try one or more of the workarounds offered here.

I want to scale the gradient bar and the scale associated with it..

You need to realize that each time your VI loops it replaces the text in the "Value" of the "source" so that at any time there is only the one number (using at most 2 ASCII characters) present. With only that one small bit of text in the text indicator, the text string is not long enough to wrap around enough to force the text box scrolling on and certainly not enough to cause there to be 29 or 30 lines of wrapped text as your example would seem to want As you probably suspect now, scroll position is not the same as cursor position. There is no cursor position control available to do what you want. The scroll control will only work if there are enough lines in the display to enable scrolling and even then you can only scroll down as far as there are lines available. Depending on word wrap to get you the number of lines that you want is a bad idea - where and when the wraps occur depend on the text indicator size and the font size - a real house of cards. :thumbdown: There are other characters you can insert into text strings that do break them into multiple lines such as your carriage return or line feed (a.k.a. new line) or the generic end-of-line character. Use one of them at the end of each line of text and build up an ever-increasing length of text and you'll end up with multiple lines and eventually the ability to set the scroll position Note however that if your text indicator is tall enough to hold, for example say 3 lines of text without scrolling, that you will not get a scroll bar and be able to set a scroll position until you get four lines of text. And, in this case, when you do get 4 lines of text you will only be able to select either scroll position #1 or position #0. When you add a 5th line of text then you'll then get the additional option of scroll position #2, a 6th line of text will give an additional scroll position #3 and so forth. If someone comes along and resizes your text box vertically so that it'll hold more or fewer lines of text then all these numbers will change. (It's beginning to look like that "house of cards" again if a change to the size of a front-panel object causes a change in the way that the code behaves.) If your only intent is to always have the last line of text showing then this won't matter; just wire a number equal to or greater than the number of lines in the display to the scroll position and the last line will always be displayed. See example. Download File:post-2800-1135094308.vi

Oops! My Bad! You simply need the index array function, assuming the data has some reasonable distribution within the 2D array. See the attached VI. Download File:post-2800-1135039549.vi

It works for me. Download File:post-2800-1135038586.vi

On the Array Palette look for (or search for) the Decimate 1-D Array function. It does what you need by "dealing out" the elements of your big array into two or more smaller arrays.

I'm having problems with LV losing track of the locations of DLL files when I move code back & forth between the development machine and the target machine. The DLL files are located in (what I think to be) the same location on both machines yet whenever I move the code from one machine to the other (direction does not matter) I have to tell LV where to find the DLL files and that always triggers a warning like this: When I am called on to identify the path to the DLLs it's by browsing from C: --> Program Files --> SI Image SGL C, yet somewhere along the way LV turns C:\Program Files into Program Files: and remembers it as such.Any idea what might be causing this and what I might do to prevent it or fix it?

In LV7.1.1 is there any way to get the color ramp to scale with changes in the VI panel size? I've tried telling it to scale the intensity graph indicator with the panel and that didn't work nor did telling it to scale all front-panel objects with the panel. The ramp always retains its original size.

It's all part of NI's new Creative Request for Action Policy. :laugh:

When I said "feed the graph" I didn't mean to be taken quite so literally. I would assume** that the clustering of the arrays, like this: is needed for LV8 just like it has always been. Sorry for any confusion. ** I say assume because I have not been masochistic brave foolish enough found any pressing need to install any one of the three copies of LV8 I have sitting on the floor of my office.

Assuming you feed the graph an X array and a Y array that define the points and if the ordering of the points within the X array is increasing then you should get a graph. You may need to adjust the line type property of the graph to "connect the dots" if all you are getting are the data points.