Yair

QUOTE (crelf @ Dec 2 2008, 09:03 PM) Saw that one coming from a mile away. Did you know that 3*5=11 for very small values of 3 and 5?

I didn't look at the code, but it was mentioned in the thread that the client assumes that the server VI is in memory, so you might have to make sure it's in the build and that it's set to run, as I've said before. It really depends on how the code is used. Alternatively, it's possible that you have a problem with the VI server ports. If your EXE has the same VI server port as LabVIEW, it will open a connection to itself. You should specify different ports for the EXE and the dev environment. This is explained in more details in the thread which was mentioned at the beginning of this thread.

QUOTE (alfa @ Dec 2 2008, 11:36 AM) 3*5=15. I hope this helps.

If you want to prevent users from accessing the block diagram, you can lock it using the security page of the VI settings, but that's not the same as deleting a piece of code when the image is deleted. Why do you actually want to delete the code? Can't you just place it in a case structure? If you don't know LabVIEW well, you might wish to go through some of these tutorials.

So if understand correctly, you want to have a VI on the diagram and an object on the FP connected to each other, so that deleting one causes the other to be deleted as well. I'm pretty sure that there's no way you can LabVIEW to do that directly. Why do you want to do this?

QUOTE (Norm Kirchner @ Nov 30 2008, 09:03 AM) Be sure to take some preperation H with you (or preperation G, since it's NI).

I'm not sure, but if memory serves, you can't open a VI's front panel without it taking focus, even if you use the method Mark mention, unless the caller is modal. It's possible that this will work with a floating VI, but I'm not sure. Here are some ideas for workarounds. I'm not sure if they're all workable: Use the input VIs to read the keyboard all the time, regardless of control and VI focus. This will require polling and some additional logic. Use the IsFrontmost VI property and KeyFocus property to return the VI and the control to focus automatically. This is probably bad, as this could happen while the user was typing. Use a subpanel to display the subVI instead of a popup.

I can't look at the code at the moment, but presumably that means that somewhere a VI reference is opened by name, and the code expects you to have the VI already in memory. If nothing in your code calls the VI, it will not be added to the executable and therefore will not be in memory. Look for the Open VI Reference function to see which VI it expects or possibly at the details of the error. You should probably be able to work around this by adding it to the list of VIs in the build explicitly, but that depends on how that VI is expected to work.

Your question isn't easy to understand, but seems to be very basic. You should start by going over the links in this page.

QUOTE (MJE @ Nov 23 2008, 03:40 PM) There might be some scripting methods for this, although I don't remember any off hand (which doesn't mean they don't exist). Personally, I like auto error handling and I think it's a good tool for catching errors you forgot to handle, so having your assertion VI have an extra error output sounds like a reasonable method, but auto error handling isn't always guaranteed to work. Another method you can try is placing a breakpoint inside a case structure in your assertion VI. Then, whenever you want to trigger the assert, simply call the case with the BP in it. One problem is that if the BP will be inside the assertion VI, you won't see where the actual error came from, but there are at least two options for this: 1. Use the source element of the error cluster. 2. When a BP pauses a VI, the font ring should change to show you the calling hierarchy and you can use that to get to the caller. P.S. If you don't mind doing it manually, you can also simply use a conditional probe, but you will lose its placement every time you close the BD.

QUOTE At least at the moment, it looks like unless people actively add comments and click that link (which is way down in the bottom), the voting is kind of meaningless for something like LAVA.

I just saw this again, which gives me a chance to re-ask the question (and fix the ridiculous typo I had in the subject).

QUOTE (Dean Mills @ Nov 22 2008, 02:32 AM) But this is new. I believe it was only changed in 8.6 and was implemented using CIN calls until now.

The point was brought up in the past.

Another alternative is simply to create a 1D array of clusters, where the first cluster element would be a string and the other two would be numerics. You can make the third an "indicator" by changing its enabled state to disabled (1). You won't be able to get it to look exactly like the table, but you can get pretty close by coloring things transparent.

If you're using the auto-tool, you can temporarily switch to the pan tool by holding down ctrl+shift. I think this doesn't work without the auto-tool, but I'm not sure. Of course, NI could also use the reasonably standard method of pressing the mouse wheel to change to pan mode, but that wouldn't work on the Mac. Then again, no one* really cares about the Mac. That'll teach them to make proper mice. P.S. This is far from the first time anyone asked for this, but if you want NI to actually see it, you should send it to their product suggestion center. * Statistically speaking. Does not apply to LV R&D engineers and LAVA admins with the ability to do bad things to my account. Valid only in the U.S. and Canada.

I can't say I understand how you would use the wheel to select, but you can read the scroll wheel information with the mouse input VIs that ship with LabVIEW. There should be an example somewhere here which shows how to use it to scroll a listbox. I've done multiple selection by simulating a click on ctrl when the user enters a listbox and releasing the click when the user leaves by using the Mouse Enter and Mouse Leave events for the control. The actual keyboard simulation was done using a simple call to the Windows API and there are many VIs both here and in the NI forums which do this. Just search for "simulate keyboard'.

You can try checking for the timeout error specifically and increment a counter if it occurs. Once the timer reaches a certain value (meaning that you have consecutive errors), you can stop the loop and either close and reopen or close and stop. Just note that you need to reset the counter if there is no error.

I can't look at the moment, but are you sure the toggle switch only responds to clicks on itself? It's quite possible that it has a bounding rectangle which is simply close to the graphic. Anyway, even if it does, it is implemented in C using vector graphics, so you can't duplicate that exact effect. You can import vector graphics into LabVIEW, but I don't remember if it does what you want. You can see more about this here.

You should note that I have actually seen people opposed to disabling OK buttons and instead describing the problem once the button is clicked. In any case, I don't think there's a single correct answer, as there will always be people who will find one method less usable than the other. Incidentally, in many of the systems I do, errors and faults are not caused by the user, or at least by an action the user does in the PC. What I usually do is pop up an error message and also have a section of the UI which shows the currently active errors. Of course, this is also only relevant for certain cases.

If you only want to view the remote panel, I believe you should be fine, although I don't remember trying it on WinCE. Controlling won't work because you need the LV RTE, which is not available for CE.

If you want NI to see this, you should also send them a message using their product suggestion center (and add a link to this thread).

In order to be efficient, SVN only stores the changes made between different revisions and not the entire file. As mentioned, this requires it to have its own format, and it packs all changes in a revision into a single file (which can be seen in the revs folder). Note that this is independent of the SVN client (i.e. it doesn't matter if you use TortoiseSVN, the command line client or any other client). In fact, you probably don't even want to go near the repository itself at all. Any interactions you have with the repository (including copying it) should be done through SVN or you risk corrupting the repository. The "svnadmin" command should allow you to do basically whatever you want, but you will need to read up on it. SVN has an online help book which is pretty detailed and you might want to give at least parts of it a reading.

QUOTE (hooovahh @ Oct 31 2008, 11:00 PM) You're generous today.

I can easily think of two options: 1. The method didn't exist back then. 2. You only think you have access to scripting enabled. In 8.x NI locked scripting access behind the license engine and the INI keys do not work like they did in 7.x. You can look through this forum for some workarounds, but nothing is guaranteed.