Jump to content

Darren

NI
  • Posts

    622
  • Joined

  • Last visited

  • Days Won

    66

Posts posted by Darren

  1. QUOTE(Tomi Maila @ Aug 8 2007, 10:44 AM)

    I think it would be better to let NI R&D to investigate what actually happens behind the scenes before writing a VI analyzer for the bug.

    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

  2. QUOTE(Ben @ Aug 8 2007, 07:30 AM)

    I wonder if Darren can develop a VI Analyzer test that will nail this contsruct?

    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

  3. 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

  4. QUOTE(LV Punk @ Jun 21 2007, 12:56 PM)

    ...but the "built-in" functions expose their graphics as a 1D array of U8s.

    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

  5. QUOTE(jlokanis @ May 24 2007, 06:17 PM)

    Does anyone know of any advantage or disadvantage to any of these methods?

    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

  6. QUOTE(crelf @ May 23 2007, 02:43 PM)

    Yeah - there are cattle ranches in Australia bigger than Texas

    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

  7. QUOTE(xtaldaz @ May 23 2007, 02:12 PM)

    I traded my XL for a L and it still swims on me. Very sad...I so wanted to wear it. :(

    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

  8. QUOTE(xtaldaz @ May 23 2007, 02:00 PM)

    But not all of us are from/in Texas. Variety is the spice of life - I know I also speak for Irene when I say that some of us look really silly in XL shirts and that's why we can't wear our spiffy LAVA shirts to work...or anywhere else.

    I wish I'd known you had an XL LAVA shirt when you still worked here, Crystal...we could have traded!

    -D

  9. QUOTE(Tomi Maila @ May 23 2007, 01:31 PM)

    Array size Xnode that always returns array size as 1d I32 array. Each element of the output array is a dimensionality of each dimension. If the input is a scalar that is not an array, an empty 1d I32 array is returned.

    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

  10. 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.

  11. QUOTE(BrokenArrow @ May 18 2007, 10:14 AM)

    Thanks Jim and Gary,

    That makes sense, that it's left over from debugging.

    Other than using a sequence, IS there a way to ensure that the delay in a loop is the last thing that runs before the loop starts over?

    I know a lot of people have wrapped the Delay function in a subVI and given it error I/O...if you do this, you can put your Delay "subVI" at the end of your error chain in your loop, guaranteeing it runs after all the other code in the loop.

    -D

  12. QUOTE(yen @ May 18 2007, 06:06 AM)

    Isn't the definition of an engineer "someone who doesn't read the instructions"?

    I saw the "Null Vote" text, but kinda didn't think about it. This is the only on-line survey I've ever encountered where viewing the results counts as a vote.

    I'll make sure to register what the words "Null Vote" actually mean the next time I read them... ;)

    -D

  13. QUOTE(Herbert @ May 17 2007, 06:12 PM)

    My favourite Austin BBQ joint is "The County Line on the Lake". Should be large enough for really big parties, but they can't score on tradition and BYOB. I also think they don't have all-you-can-eat. So, I'm in on the Salt Lick.

    Herbert

    County Line on the Lake does provide an all-you-can-eat group deal...at least they did when I went there in Fall of 1998 with about 100 other senior engineering students... :)

    -D

  14. QUOTE(Aristos Queue @ May 17 2007, 03:15 PM)

    Yeah, I voted for "somewhere else". But after that I realized I didn't have a better suggestion, and seeing as how everyone else is good with Salt Lick, just pretend like my vote was for Salt Lick too.

    Hey, at least you got to vote...it says I've already voted, but all I did was view the results without voting. I demand a recount!

    Actually, I was also going to pick "somewhere else" since the Salt Lick is in BFE, but I really couldn't think of a venue in Austin that can accomodate such a large party and provide the amount of food that The Salt Lick provides.

    Bring on the meat!

    -D

  15. Alrighty, here it is. Create a directory under your My Documents\LabVIEW Data folder called "VI Analyzer Tests". Put the attached LLB in that folder. Now, the next time you launch the VI Analyzer, you'll have a new category in your tests list called "User-Defined Tests" that contains the Find VI Calls test. With this test, you can specify the names of VIs (as strings), and the test will find any instances in your VIs of subVI calls to this VI name, along with any string or path controls/constants that contain the VI name (in case you're calling it dynamically). If you're not looking for instances of Globals, you can ignore the "Types of Globals to Detect" option on the config page (I added this for somebody who needed to only find a certain type of a certain global).

    This VI Analyzer test is saved in LabVIEW 8.2.1 and is only compatible with VI Analyzer 1.1 and later (the current version as of today is 1.1). I hope it helps, let me know if you have any problems using it.

    -D

  16. QUOTE(i2dx @ May 2 2007, 12:42 PM)

    hmm ... that's really sad. If you want I can write you a PM, than you have at least none :D

    That reminds me of a line from the now-canceled HBO show "Lucky Louie":

    "Do you know how much money we have in our bank account? Negative 50 dollars. We have to *raise* 50 dollars to be broke."

    -D

  17. There are a couple of internal errors in LabVIEW called "DWarns" and "DAborts". You'll get that dialog on launch if a DWarn or a DAbort occurred on the previous run of LabVIEW. A DAbort is a crash, but a DWarn could be some internal error that LabVIEW logged, but LabVIEW was still able to continue operating normally. If you click the "Investigate Internal Error Now" option, you'll be taken to a webpage that will perform a search of the NI Support site to see if that internal error has any KnowledgeBase entries associated with it. Assuming your error does not, you can submit your log file to NI Tech Support, who sends all of these error reports on to LabVIEW R&D. If you can reproduce the DWarn/DAbort with some simple steps, it would also be helpful to submit a sample VI (if applicable) along with the error log.

    Hope this clears up the issue, let me know if you still have any questions.

    -D

  18. QUOTE(gleichman @ Apr 9 2007, 02:51 PM)

    • The report generation llb "NIReports.llb" was over written over the standard llb. Make a backup of this file before installing if you use the Report Generation Toolkit.

    There are other Report Generation Toolkit LLBs that get overwritten by the 8.2.1 install besides NIReport.llb. I recommend uninstalling the toolkit first, then installing 8.2.1, then reinstalling the toolkit (this problem is mentioned in the 8.2.1 readme).

    -D

    P.S. - We are looking at ways to ease the LabVIEW/RGT integration pains in a future LabVIEW version.

×
×
  • Create New...

Important Information

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