Yair

As said, the most likely source of your problem is a race condition caused by working on the same resource (the list of strings) in two places without locking it, but without seeing the code it's impossible to tell for sure. The solution is either to lock it or to handle it in a single loop. The more generic solution would be to disconnect the display from the underlying data and logic. For example, you can have one loop and a cluster of your data which is passed through a shift register. One of the elements in that cluster would be the array of names or the data needed to build that array. Your logic would actually operate on that data (by unbundling and bundling by name) and you then call a display state which will translate the data into your display. You can see some examples if you search for "state machines" or look at some of the templates you get when you select File>>New. There are links to some tutorials here.

QUOTE(tcplomp @ Feb 20 2008, 02:52 PM) QUOTE(Dirk J. @ Feb 20 2008, 03:34 PM) nothing really, I guess. Except for the hidden FP control, which I don't like either.

You could start by disabling the terminal icon view. This is both an environment option and an option specific to each terminal. Then, you can clean up your diagram and it will be smaller. You should also note that the terminals are not equivalent to variables. The closest thing to variables are the wires coming from the terminals, which you can't get rid of. You might wish to use an array of strings and use the Array to Spreadsheet string primitive to save some space in this example.

I'm not sure if you noticed Ton's original reply, but Wait Until Next MS Multiple is the wrong choice - it WILL wait until the next multiple, so if your code finished at xxxx36.001, it will wait an extra 2 ms until it will get to xxxx38. A better timing structure is the timed loop, but I'm not sure if it's available on the QNX. Another alternative is to place a 0 ms wait. This should tell the OS to run this as fast as possible if nothing else needs the CPU. Additionally, playing with the VI priorities might get you better results.

The CPU can definitely process code at a very high speed, but it is correct that you can't get guranteed (deterministic) results, for one simple reason - Windows is not a real-time OS and as such can correctly decide that it wants to do something which is more important than what LabVIEW is doing. If that other thing takes all of the CPU, your computations will be delayed by an unknown period of time.

QUOTE(Aristos Queue @ Feb 15 2008, 11:29 PM) And you probably do all the programming in your head, right? "10001110100101101010110101100011010101011101010101000101010100010101010101010101101101011101010 0110101010101101010001010101110101010101011010101110101010101000101010101010101010111110101010110101 10101101110101010001010101100101010"

P.S. Known issues: In LabVIEW 7.0, the first call to the dropping method after starting LabVIEW takes several seconds and sometimes changes the focus to another LV window when it's done. This doesn't happen in 7.1 and above. On very rare occasions, I have seen some issue with the call to the top-level VI. I don't remember the specifics (it's been a while since I've last seen it), but I think it wouldn't let me close windows. The solution, once you know it, is simple - opening the hierarchy window allows access to the proxy caller, which can then be aborted. I didn't make the delete\rename a proper dialog, so it still has the menus, scroll bars and tool bar. The change is simple. The files I attached are not fully compatible with 8.x. Some of the names have been changed in 8.x, so you can just add them as they come or rename them.

You can use an event structure and capture both the value change and double click events for the listbox. This won't give you the hovering behavior you want, but you can do a combination of a mouse enter event followed by mouse move events to figure out which element you're over. I know that tables have a method for this, so it's possible that listboxes have one as well. You can find some tutorials here.

OK. So here's the version I've been using for the last 3 or 4 months, along with some files I created. Extract it somewhere and read the readme file. I would especially recommend this to anyone using 8.x. The little experience I had with 8.x seems to suggest that accessing the palettes is very annoying and this gets around that. Important note - the code is not meant to be pretty or clever. It was put together over some time partially as a proof of concept in coding sessions which were usually done at night, so don't expect quality code here. It works just fine and if the issues described in the rest of this post are overcome, will probably also be cleaned up. In case you're wondering, the main design criteria which led to this structure was the wish to avoid memory allocations of the large string array, but I haven't been too zealous about actually doing it so far, since I didn't run into performance issues. The list files attached here are not the files I actually use (they don't have preference values or aliases) but they should work. However, they also demonstrate the problem I currently have nicely. A lot of things change over time. For example, the dialog controls in 7.x are now called system controls in 8.x. I have a basic design (and code) for how to run files which will automatically upgrade the relevant names, but the problem is with creating a usable interface for creating those files. To be honest, I haven't put too much thought into it so far, so I wouldn't mind hearing suggestions. Essentially, what is needed is a method of recursively scanning a directory or a set of palettes and generating a list and then comparing that list to a previous version and letting the user decide what to do with the names which are different. I already have code for scanning a folder hierarchy and then to attempt dropping those functions. All those which can't be dropped are discarded. This is what I used to generate the lists attached to this post. I also have some code which uses the palette API, but it didn't seem to play nicely with the primitives and with older LabVIEW versions, so I didn't look seriously into it.

I think the problem might come from the file I/O, not the wait itself. If you do a test where the VI just waits, you should see that it behaves as expected. I seem to remember that some I/O operations halt the LabVIEW root loop and this might be what's causing this. If it is, I would assume that it is a bug or at least should be officially brought to NI with an example.

This is certainly very impressive and could be immensely useful in sharing code online. Thank you. One thing that is important to note is that for this to be usable by wide audiences it will have to have a one-click usability. For the CCT we went to some effort to make it very easy both to install and to use. Ideally, when a user generates something like this, they should end up with an easy way of building a path to embed this as a Flash object.

QUOTE(tcplomp @ Feb 15 2008, 07:21 AM) I think http://www.starwars.com/databank/character/chewbacca/' target="_blank">Chewie might take some offense at being called "cartoonlike" and you probably don't want to be there when it happens.

Thanks. Unlike the new VI object ring, this doesn't include controls (I guess most don't have help topics), but it's definitely a good list. I will post the version I'm currently using tomorrow, along with some files, just so that we have a common baseline to talk about.

Thanks for the suggestions QUOTE(Jim Kring @ Feb 14 2008, 10:21 PM) Can you elaborate on that? I actually find it quite convenient, since if I want the original functionality all I have to do is take my finger off the N key and then click it again. QUOTE I would add an option to the Tools menu to start up the tool and have it run behind the scenes waiting on a configurable key combination. This will probably improve performance (although at the moment I don't see a need to), but the main problem with this is that the tool will then stay in memory even when all other VIs are closed. I was considering using the Set Close if Lonely property, but I haven't looked into it yet. What I actually need now are ideas on how to build a viable system for scanning, exporting and importing aliases so that people can relatively easily create files for new toolkits and versions and distribute those files to other people who will then be able to easily integrate them into their existing setup. Essentially, my current plan is having a configuration style file for each toolkit which will define transformations between versions and I already have the basic format. The real problem is creating this file - the user who creates that file needs some reasonably easy interface which will allow specifying for each VI whether it is new, renamed, deleted or any other option. I'm open to suggestions.

Knowledge of video games would certainly help to appreciate this video:

Thanks. Unfortunately, 7.0 doesn't have the methods for importing custom images, but this is also nice.

Can anyone please backsave the code (or at least the control) to 7.0?

Here's someone worse than alfa. I kind of feel sorry for him.

Oh, sorry, I didn't notice you posted to the hardware forum. The only intelligent (and not particularly productive) thing I can say about physical control panels is that buttons with embedded LEDs are cool. They require an extra digital output, but I like them.

<cite>QUOTE(cmay @ Feb 8 2008, 07:11 PM) </a></cite> We have such a button in the CCT. I don't remember what we did off hand (my guess would be that we took a path control, hidden the path behind the button and used a transparent boolean over it, so that it's actually two controls), but you should be able to do the same. You can also probably simply get the image by customizing the dialog control (I seem to remember that it can be done), but that will probably mean that the image of the control will not change when you change Windows versions or themes.

The tab looks reasonable, but could also be implemented using any number of tricks. In any case, if I understand what you want correctly, why not just use the numeric value of the tab? Since the tab can't change, there shouldn't be any bugs and since you shouldn't care about the actual value (only the VI which does the caching needs to), there is no actual need to have it as an enum. If this doesn't help, I suggest you post a piece of code displaying the desired functionality. P.S. This is unrelated, but you should avoid mixing LabVIEW and system controls, since system controls can change with OSs, OS versions and OS themes and make your UI look weird if they are mixed with controls which don't change.

Maybe it's just me not understanding, but if the controls are all hovering over the tab control, what use does the tab control have? Why not just use a bunch of buttons or a listbox to indicate which "page" was selected? Can you post an image of the FP?

Maybe it's just me, but I don't understand the question. If you are refering to the connector pane, here are a couple of tips: Use standard patterns with terminals to spare. 4-2-2-4 is popular and has been made the default in recent versions. Try to keep a consistent style. Again, a common pattern is using the top two corner terminals for references going in and out and the two bottom corner ones for error wires. Make any input required unless it has a reasonable default value. If it does have a default value, write that value in parentheses as the end of the control's caption (which is what appears in the connector pane).

If you have the professional version of LabVIEW, you should have a palette with VIs for generating reports. One of them accepts a 2D string array. There may be examples for how to use it in the example finder.

QUOTE(neB @ Feb 5 2008, 07:08 PM) Yes. You get a warning and the ability to choose whether you want to replace all the copies or not.