Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Darren

  1. Seems to work fine on other apps, too. Any reasons we should use this approach instead of just killing the desired process from Task Manager? -D
  2. I'm seeing the unsaved changes prompt on my 8.5 project, too. In my case, it's because I'm using auto-populating folders. I filed a CAR on this, maybe the one referenced by the previous poster. I haven't seen the weird Semaphore/Rendezvous thing, though. -D
  3. QUOTE(dwisti @ Sep 22 2007, 10:08 AM) To my knowledge, if you have the FPGA module installed, you can use fixed/bounded arrays in FPGA VIs or in normal VIs. -D
  4. QUOTE(Jim Kring @ Sep 21 2007, 05:16 PM) Yup, but those VIs are only working with the type of the variant...they don't do anything with the value. And I don't suspect that will change. Remember that these VIs are the next generation of the type checking VIs that used to work on the I16 type array, they just use a variant now. I agree, though, that it would be helpful for the context help to indicate the specific behavior of the "size" output in relation to the "type" input. In fact, I'm pretty sure I was the one who did a code review with the author of these VIs before he added them to LabVIEW back a few versions ago, so I'll take partial responsibility... -D
  5. QUOTE(Jim Kring @ Sep 21 2007, 01:35 PM) Hi Jim, I don't own these VIs, and I haven't seen the CAR, but my guess is that the "size" output is only valid for Fixed/Bounded arrays. Notice the "Type" output in the "Array Lengths" cluster of this VI. If the Type is Fixed or Bounded, I'd imagine you'd see a size there. Since these VIs are only analyzing the type data of the variant, they would have no way of knowing the size of a standard array in LabVIEW (returned as the "Variable" Type in that cluster). But for Fixed/Bounded arrays, the size is part of the data type. Hope this helps, -D P.S. - Fixed/Bounded arrays are a feature of the LabVIEW FPGA Module, as discussed http://zone.ni.com/reference/en-XX/help/371599B-01/lvfpgahelp/creating_fixedsize_arrays/' target="_blank">here.
  6. For posterity, an easy way to create a new VI is to just use Open VI Reference on an empty template VI. Then you can do Open FP, or whatever other operations you wish, with the new instance of the template VI you just created. -D
  7. That was good for a laugh...thanks, guys. -D
  8. QUOTE(Justin Goeres @ Sep 8 2007, 12:24 AM) Yup, I love cryptic crosswords. The only place I've seen them is GAMES magazine. Usually takes me a couple of days of off-and-on work to finish one. -D
  9. Ok, hopefully this will make things easier. The menu item I hijacked was Tools > Measurement and Automation Explorer. I don't know what version of LabVIEW this option was introduced in. Probably 8.0 if I had to guess. Anyway, I never use this menu option, so it was a good candidate for my prototype. This menu option launches project\max.llb\MAX Launcher.vi. If you replace that VI with your own VI, then whatever key combination is assigned to Tools > Measurement and Automation Explorer will launch your VI instead. In my case, it launches my Quick Drop prototype. I changed the key assignment (with Tools > Options > Menu Shortcuts) to Ctrl-Space which is easy for me to type with my left hand, and isn't currently assigned to anything in LabVIEW on Windows. Hope that helps, -D
  10. QUOTE(yen @ Sep 3 2007, 01:57 PM) For my prototype at NI Week, I didn't need to do any polling. I'll give you a hint...I found a VI-based utility that you can launch from a keystroke in LabVIEW, and I hijacked it by putting my Quick Drop VI in place of the existing utility. -D
  11. ...and I'll throw in some parsley to garnish the gruel for an explanation of the two Always Copy and Swap Value nodes to the left of the "Do Not Delete" Sequence Structure. -D
  12. QUOTE(eaolson @ Aug 16 2007, 05:45 PM) I ran into this problem in a recent project...I was able to work around it by changing my picture control into a 2D array of picture controls, where the picture control element in the array had no border (so the pictures in the array all sit next to each other, and it *looks* like one big picture). Turns out using the built-in scrollbars on the array control looks fantastic, with none of the redraw headaches I had before with the single picture control. The only drawback is that scrolling the array takes place in an incremental fashion. For me this isn't a big deal since the UI I was constructing was more or less a grid in the first place, so scrolling in increments of one grid space (i.e. one element of the array) actually looks pretty nice...never have to worry about half a grid row/column being visible in the UI. -D
  13. QUOTE(Tomi Maila @ Aug 8 2007, 10:44 AM) Well alrighty then...let me know if/when you guys want me to write a VI Analyzer test for this, and what specifically it should detect. Another idea I had was that the test could have a configuration option that would return a failure for *any* Value property on the diagram, as long as there is something wired on the conpane. That way you could sift through them yourself to make sure none of the non-implicit ones would cause the problem. Also, I noticed the Val(Sgnl) property also demonstrates the bug. -D
  14. QUOTE(Ben @ Aug 8 2007, 07:30 AM) I read through this thread a few times to get a better grasp on the problem. It seems to me that you would want a VI Analyzer test that detects whenever the Value property is written for a control that is wired on the connector pane. Does that sound right? I could write a test that would detect this case for implicit property nodes pretty easily, but for property nodes with control references wired to them, that's a different story. I could detect the Value property on a property node that is wired directly to a control reference, but once you start getting into cases where the control reference is passed through a loop border, a subVI, other property nodes, etc., it becomes much more difficult to develop. So as it stands, I could pretty easily write a test that would detect implicit property nodes (or property nodes wired directly to control references) that are writing the Value property for controls on the connector pane. Would that be useful? Please let me know if I missed the mark and the test should detect something different. -D
  15. One of my favorites is Aristos Queue's scrolling LED XControl. -D
  16. Maybe try clearing your browser cache? -D
  17. I have a few suggestions for you. First of all, don't select all 4 Office support options in the installer, all that does is install each of them one at a time, where each subsequent selection just overwrites the files of the previous one. For installation purposes, you should only select whatever version of Office you currently have on your machine. If the version of Office on your machine changes, you need to uninstall/reinstall the toolkit to update your Office version-specific files. We are looking into ways of alleviating this confusion in future versions of the toolkit. Next, I assume you're building executables of your application for distribution? If so, you should follow the instructions for building executables in the Report Generation Toolkit User Guide. I have attached the latest User Guide (version 1.1.2) to this post, since it has the most updated instructions regarding building EXEs with the Report Generation Toolkit. Now if you are distributing the EXE to users with multiple versions of Office, you will need to create an EXE for each different Office version. Even though only the Office 2003 files are installed on your computer, when you build the EXE, you can include the dynamic VIs for any Office version by accessing the version-specific files in the "Compatibility" folder on your Report Generation Toolkit CD. Finally, I should point out that the latest version of the toolkit is 1.1.2. It is a free upgrade for users of version 1.1.1. It includes various bug fixes, along with support for Office 2007. The installer for version 1.1.2 only supports Office 2000, XP, 2003, and 2007. But the "Compatibility" folder on the RGT 1.1.2 CD still contains the Office 97 support files. Please let me know if you have any other questions. Again, we're working on ways to make this a much easier experience in future versions of the toolkit. -D
  18. QUOTE(LV Punk @ Jun 21 2007, 12:56 PM) Wow, I'm impressed. I tried to reverse-engineer the palettes a few months ago with that method and I didn't get nearly as far as you. Looks like your images are correct other than the coloring, which is a lot farther than I was able to get. Anyway, here's a hint I learned...if you write the U8 "image" array of a palette object to a binary file, you'll have a .emf file that contains the palette image of that object. I studied the .emf file format and was able to extract all the header information in G, but I gave up when I tried to start parsing the actual .emf drawing commands that appear in the file after the header. At that point I looked around for a G-based EMF file reader, and the only one I could find was in George Zou's G Toolbox. And at that point, I actually took a different direction in the project and didn't need to take the EMF approach anyway. Nice work, -D
  19. There's the Palette API posted on the NI Community website...this would be a good place to start if you've already got .mnu files that you want to present to the user in your own manner outside of the LabVIEW palettes. -D
  20. QUOTE(jlokanis @ May 24 2007, 06:17 PM) Methods 2 and 3 (property node ref and This VI ref) are functionally the same if you don't wire the output of whatever property you're reading. They return a "Self Reference" to the VI that does not need to be closed. Instead of dropping a control ref and re-linking it to the VI, you can drop a "This VI" reference from the Application Control subpalette. Ooh, now that I think about it, that reference may drop as "This App" instead of "This VI"...I don't have LabVIEW open right now. Either way, This App/This VI are the top two choices on the top of the list when you operate-click the reference. Hope this helps, -D
  21. Darren

    Annual LAVA/OpenG BBQ

    QUOTE(crelf @ May 23 2007, 02:43 PM) My rudimentary web searching skills are revealing the largest ranch in Australia to be about 30,000 sq. km, and Texas is about 680,000 sq. km. What else you got, Dundee? -D
  22. Darren

    Annual LAVA/OpenG BBQ

    QUOTE(xtaldaz @ May 23 2007, 02:12 PM) I wear my 'Large' LAVA shirt sometimes anyway, even though it makes me look like I should be in a Will Ferrell SNL skit. Some chick in downtown Austin actually asked me one time (when I was wearing my shirt) what LAVA was. Her eyes glazed over after I mentioned computers. I think next time I'll make up something about volcano worship. -D
  23. Darren

    Annual LAVA/OpenG BBQ

    QUOTE(xtaldaz @ May 23 2007, 02:00 PM) I wish I'd known you had an XL LAVA shirt when you still worked here, Crystal...we could have traded! -D
  24. QUOTE(Tomi Maila @ May 23 2007, 01:31 PM) The feature I've been wanting that would be well-suited for one of these mythical "XNodes" would be a growable Array Size function, that returns 'n' scalar "dimension size" outputs, where 'n' is the number of dimensions of the array. I would much prefer this to the current method of dropping an Array Size and an Index Array. -D
  25. Darren

    Annual LAVA/OpenG BBQ

    Hey, if there's another T-shirt giveaway at the BBQ, make sure to bring plenty of Extra-Larges this time. Remember, everything's bigger in Texas. -D P.S. - Seriously, I'm guessing you guys like the idea of me wearing a t-shirt with a big ol' LAVA logo to work...but I'm guessing my LabVIEW R&D colleagues don't want to see me in a tight t-shirt of any variety. P.P.S. - haha, I'm glad to see my 100th LAVA post was something classy like this.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.