Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/21/2013 in all areas

  1. Maybe you guys are a little too hard on this fellow. Personally I enjoy unusual 'educational' threads like this. Actually some of my favorite threads ended up with someone getting kicked off the list
    1 point
  2. Put these files in <LabVIEW>resourcedialogQuickDropplugins and Bob will be your Quick-Dropping uncle. Ctrl-space, Ctrl-e will activate the plugin. It'll ask you for Right Click API.llb, so you'll have to have the RCF installed somewhere. (It'll be in <LabVIEW>vi.libaddons_JKI ToolkitsRCF API). These are type-defs for a control on the password-protected VI Vishal Devanath gave us. Now, as far as Flarn2006 hacking it for us, most of us can get at the block diagram without much effort but it's "wrong". QD_RetainWireValues.vi Retain All Wire Values core.vi
    1 point
  3. And a couple more things I didn't notice earlier: Your init VIs are in the control class, which is a no-no. The control class should not be required to know about its child classes. Instead, have a separate init VI for each class inside that class (you will still need to give it a full name to avoid having LV think it's a DD VI). You can collect these into the PolyVI I mentioned earlier. The Control class then has a set ctl ref VI, which is the VI these init VIs call to put the ref into the object data. If you want to protect it, you can make it protected scope, which should still allow the children to call it. You might wish to follow the VI Server hierarchy exactly. The Ring class actually inherits from Control>>Numeric>>Named Numeric. Likewise, implementing the actual classes yourself would mean you didn't have to rely on the LV UI, but that is really a lot of work and is probably not worth it. And regarding that last part, I only now really looked at what you're doing, and I'm not sure I understand the point. Sure, this could work for the idea in the IE, but is there anything else it's good for? In many ways, the VI server API already works like DD VIs do, so there shouldn't be a need to wrap it.
    1 point
  4. That's the one! Of course the VI just makes a call to a bunch of system DLLs, so I don't think it would work on Linux/Mac/Etc. Ultimately you're really not gaining anything over .NET other than you don't need to deal with it directly. The snippet above probably doesn't require the file/directory info primitive, but I've always used it as such and not found with any trouble. I'd love to play with some scripting or use j's code to have version info in the IDE, but that's so low on the priority list since ultimately the application is always distributed in built form.
    1 point
×
×
  • Create New...

Important Information

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