JDave

QUOTE(young grasshopper @ Sep 12 2007, 12:28 PM) When you increment it, the enum is coerced to an integer. You need to coerce it back using a 'Variant to Data' function. http://lavag.org/old_files/monthly_09_2007/post-1519-1189625727.png' target="_blank">

You need to use VI Server. Open a reference to the VI you want to run in parallel, then use the "Run VI" method from an invoke node. Be sure to wire a False to "Wait Until Done". That spawns the VI into a separate process. David EDIT: Looks like there is a Wiki Article that has a little bit of information (mostly what to avoid, not how to implement).

QUOTE(HChandler @ Sep 12 2007, 11:30 AM) You're referring to buttons and code logic that we can't see. If you upload your code, we can see what is wrong.

QUOTE(Ben @ Sep 11 2007, 12:59 PM) I think the issue is using the VI Method to set control values by name, versus using the control properties to change value or other properties. To do what you want to do, you need to access the control by reference. You can pass the reference around, or you can get the control references from the VI in question (VI >> Panel >> All Controls) and search for it by name. If you are already using the VI ref only, this would be the easiest transition. Just be aware that if you have any nested controls (clusters, tabs, etc.) you will need to recursively search through these.

I found a few threads (like this) that talk about calling plugin VIs. I thought that the connector pane would be an easy way to verify that the plugin is valid. Having played with the LV 8+ replacement for the Icon Editor a bit, I noticed that they require a certain connector pane in order for your replacement VI to be valid. Here is the interesting thing, though. They allow you to connect terminals that are unconnected in their template connector pane. But then it would seem that using the Call By Reference Node would be unavailable because it requires a strictly typed VI with an exact match on the connector pane. Does anyone know of a way to check if a VI matches a template connector pane, that ignores unconnected terminals in the template? The plugin may or may not use these terminals and it should not matter. Can I mimic what the Icon Editor does, or is this just not feasible? David

QUOTE(TG @ Sep 10 2007, 10:36 AM) Yes, the pain caused by missing features just shows how much we appreciate this forum!! I found that searching for the word 'the' within the last 7 days returns most if not all of the new posts. It seems that trying to jump to the new post in the thread doesn't work. But it is a workaround in the meantime.

QUOTE(Darren @ Sep 7 2007, 08:45 PM) Were you able to change the menu item text in the Tools menu? I couldn't

QUOTE(yen @ Sep 7 2007, 06:20 AM) Yes, some of the hooks are there. Some of those hooks are private, some more are missing. By option #2, I meant public supported extensibility. QUOTE(yen @ Sep 7 2007, 06:20 AM) IN ANY CASE, this is hijacking the thread. If you want to discuss this more, I suggest you start a new thread. What I want here is VIs, ideas or suggestions for efficient algorithms for handling the searching. To repent for continuing to hijack the thread (Sorry ) , I offer some thoughts on the true thread topic. I think that using this type of tool to search for VIs or functions would simply duplicate the Search functionality that already exists. If I were to use a tool like this, it would be to quickly drop my commonly used functions. This would mean that I would want aliases that I could enter and done. If I wanted a for loop, I would type Ctrl+N, f o r, then Enter. Perhaps you could primarily search in a list of aliases the user has built up. Secondarily if the user wants to search, then you could load the entire list and auto-complete or whatever else would help.

QUOTE(Jim Kring @ Sep 5 2007, 06:25 PM) I have yet to look fully into this, so I just have a few general questions. Does the OGP format handle unique code for different versions, or do you have to develop the code in the lowest version possible and have only one chunk of code? This is not a common problem, but you can't always go back to even version 7.x with some code. Does the OGP file use the existing menu file on the development machine to allow the OGP installation to also have menus on the palette? I didn't see anything in the new VIPM beta version about building packages. Is this something upcoming soon? Thanks.

QUOTE(Tom Limerkens @ Sep 6 2007, 12:49 AM) That would be an option for me. I will try it out, Thanks!!

QUOTE(Val Brown @ Sep 6 2007, 01:48 PM) That's precisely the problem IMO and one of the main reasons that, while I support open source efforts (esp things like OpenG!), I will NOT use the tools in any distro. I know that's probably a minority opinion (esp here!) but here are some of my reasons. I am not sure what is precisely the problem. That it is a hack? Or that the extended IDE would be third party, and thus not something that NI will support? QUOTE(Val Brown @ Sep 6 2007, 01:48 PM) 1. I pay for Platinum Support so I konw the ONE source I can ALWAYS go to and get, in the end, the Final Answer. Yes, I LOVE the support that we get here ---- [sounds of applause] -- but I don't count on it for distros. I want someone or some entity that is ultimately responsible and actionable if things go south. 2. I want one, single licensing environment so I don't have to worry about whether I've included BSD, BVDs or valentine's that acknowledge the latest Easter Eggs. These are valid points that each programmer or organization must take into account. QUOTE(Val Brown @ Sep 6 2007, 01:48 PM) 3 I want to be able to walk up to ANY system and simply BE ABLE TO USE IT. I do NOT want to know (and I especially don't want to HAVE TO KNOW) that on "this system" CNTL-Q closes an app but on "that system" it launches the missles, so don't forget to call Moscow as soon as possible. I'm all for customizability but I do not want to have to rely on it for me to be able to do my work. I completely agree that changing the way the LabVIEW IDE works from one system to the next is confusing and is a 'hack'. Extending the IDE is the decision of the developer to put additional functionality into the IDE -- that does not mess with the original behavior. Thus any developer would still be able to use it because all the base functionality is the same. So while I think it is cool that I can hijack a Tools menu item, it is also sad that I am breaking the IDE in order to extend it. In the end, there are things I want to do in the IDE that aren't available. Where is the built-in Tunnel Wizard? Or something to color nested structures with alternating colors? Where is the ability to select multiple controls and hide the labels on all of them at once (or any other common property) ? I would love to see these available in the LabVIEW IDE. In order of preference, this would be possible by NI incorporating additional IDE capability into future versions of LabVIEW. If they incorporate what I want, lucky me. NI providing extensibility to the IDE so that third party groups (or myself) could implement what NI didn't. Extending the IDE inspite of itself, aka hacking the IDE. The third option is the worst, and it is what Darren did by hijacking a Tools menu item. It is what yen is doing by overriding the Ctrl+N callback. It is what I plan on doing for my own fun stuff. But this should not be migrated to other machines unless the new owner is fully aware of what is being done. Kind of like the Rusty Nails warning about scripting. Fun stuff, but beware. So while #1 would be great, and it would allow NI to support everything, I think #2 is necessary. Then you could have a suite of OpenG IDE extensions that aren't incorporated into the distro, but would be used to facilitate coding up the distro.

QUOTE(Michael_Aivaliotis @ Sep 5 2007, 07:51 PM) My latest CR submission was written in version 8.2. I originally started writing it in 7.1, but there are new control properties in 8.2 that give more information. Plus some subtle changes in how events were handled required a change. So the code for 7.1 is distinct from 8.2. QUOTE(Michael_Aivaliotis @ Sep 5 2007, 07:51 PM) Otherwise, just indicate the latest version and please put all the other versions in the description. Sounds good. :thumbup:

QUOTE(Justin Goeres @ Sep 5 2007, 04:26 PM) These are really cool VIs (at the top of Jim's list, even), and the ones you refer to take the VI's whole front panel at one shot (one VI !!) I am not sure what was meant by flexibility. I interpreted that to mean that the control labels may change, which would break the configuration file. Using the OpenG solution would give you this same dependency and problem. Maybe ease of use was most of the flexibility issue, and if that is the case then the OpenG toolkit is the way to go.

I have an PXI RT system hooked up via ethernet to my Windows XP computer. When I boot up the PXI chassis, Windows takes over one minute to connect to the device. I assume it is making sure that my PXI chassis doesn't have internet access. Does anyone know a way to tell Windows to stop looking so hard? Can I change the timeout before it returns and tells me that my device is crippled because it has "limited access"? Thanks for any suggestions, David

If I have code that I want to make available in multiple LabVIEW versions (e.g. 7.0, 7.1, 8.2) how do I go about doing that? If I put the different versions in the zip file, how do I indicate that when loading the new file? The CR page states what the LV version is, so would I just put some notes on the description stating that there are actually several LV versions contained contained in the zip file? Thanks, David

QUOTE(Randy81 @ Sep 5 2007, 01:21 PM) One easy thing to do is to have a conversion VI that converts configuration keys to control labels / references. That gives you a layer of abstraction between the config file and your control labels. Any change to the labels just requires a change to the conversion VI, and doesn't affect your configuration files.

QUOTE(yen @ Sep 5 2007, 12:04 PM) I understand. That was my sentiment when I mentioned earlier that this is not for mass markets. QUOTE(yen @ Sep 5 2007, 12:04 PM) No, that was what I did in the demo I uploaded. The voodoo is VI callbacks. You can get LV to run your VIs if you give them special names and connector pane patterns and put them in the LabVIEW x.x\resource\plugins folder. In this case, I believe I created a VI called lv_exit.vi which is called when you try to exit LabVIEW (e.g. by pressing Ctrl+Q). I can look up the documentation tomorrow if you want. My problem was that I couldn't get it to abort the exit sequence and it always tried to close the VI I was calling it from. The problem with menu shortcuts (apparently) is that they don't stick. When you restart LabVIEW, you will lose them. If I understand correctly, aren't you still hijacking an existing item? The only VIs that can have shortcuts attached to them in that folder are items that are already in the menu, right? I must be missing something. What is different with overriding something in the resource\plugins folder instead of overriding something in the project folder?

QUOTE(yen @ Sep 5 2007, 10:59 AM) Why not? If you can hijack a tool you don't use, then no problem. It is a hack, but as Michael mentioned earlier that is a problem that NI has to deal with. There are people who are trying to extend the IDE, and they really want some hooks to plug into. Capturing the hotkey in a background daemon is still a hack. But then maybe you use all the existing tools... QUOTE(yen @ Sep 5 2007, 10:59 AM) Using some LV voodoo, I did make a successful attempt to intercept the not-really-used Ctrl+Q (instead of Shift+Q), but I can't get LV not to try to close the VI, so you get the close dialog after dropping the control. I might try to work on that angle a bit more. Is this voodoo a VI that constantly monitors for key strokes? If so, how would you deal with correct hotkey combinations, but at the wrong time -- i.e. when another application has focus? And why are you using an existing key combination (Ctrl+Q) ? LabVIEW will always capture this. You can change the menu shortcuts (is that LV 8+ ?) or you can choose a shortcut that isn't used, like Ctrl+Shift+Q.

QUOTE(Darren @ Sep 3 2007, 07:19 PM) Ooohh, hijacking existing tools to use their hotkeys. :ninja: Now that is a nice idea. Not for the mass markets, but if you just want your tool to have a hotkey...

QUOTE(orko @ Aug 31 2007, 08:33 AM) The problem, I believe, is that the search only looks in the base diagram. It does not look in any structures (while loops, case structures, etc.). There is a VI in vi.lib for traversing the diagram hierarchy. That should do the trick. On the topic of the name, would this also break if there was more than one instance of the subVI on the block diagram? Wouldn't it always stop on the first instance found, rather than search until it found the correct instance? David

QUOTE(yen @ Aug 31 2007, 05:59 AM) Maybe in the last three years they have upgraded. It is nice to see functionality like this be available. :thumbup:

QUOTE(alfa @ Aug 30 2007, 01:22 AM) QUOTE(jpdrolet @ Aug 14 2007, 05:39 AM) alfa, June 2006: 97.7% of population are at animal level. alfa, April 2007: 97.73% of population are at animal level. alfa, August 2007: 98% of population are at animal level. So are we at 99.92% now? QUOTE(alfa @ Aug 30 2007, 01:22 AM) 1299 in 1300 people need simple things about spirituality like: God create them, they go to Heaven….

QUOTE(orko @ Aug 28 2007, 12:14 PM) Is this persistent for you? I have problems with this on my system. First I only get one item to show up in the Menu Shortcuts area even though I have three tools in the wizard directory. Second, the shortcut that I set disappears when I restart LabVIEW. This happens for my 8.2.1 and my 8.5 evaluation. I see a listing in the LabVIEW config file, but it still loses the shortcut on restart. Is this just me? David

QUOTE(george seifert @ Aug 28 2007, 07:45 AM) A workaround solution would be to write a little scripting VI. This would be really simple, and you could add it to the Tools menu. I threw this together real quick, but it works. Written in 8.2, but the same idea would work for 7.1. And to NI, it would be really nice if one could make shortcuts to custom tools in the Tools Menu... hint, Hint, HINT! http://forums.lavag.org/index.php?act=attach&type=post&id=6780 http://forums.lavag.org/index.php?act=attach&type=post&id=6781 P.S. Yes, some hinting has already been passed on the the NI Suggestion Box. Some more can't hurt. David

QUOTE(orko @ Aug 24 2007, 10:39 AM) I hope something works out for you, even if it means moving elsewhere. Now it seems you should change the thread title to "Available"