crelf

Oooooooooooo - that's nasty! I assume you've already told NI? If so, can you link to the thread or post a CAR #?

Idea: can you select the build items in the correct order (Ctrl + click) and then hit build selected? I seem to remeber that working back in the earlier 8.x days...

I assume you mean it's more important to have a LAVA Repository than it is to have a LAVA label in the product or filename. Right?

I agree.

*exactly*! And then we could talk about how VIPM users can either automatically or manually connect to the repository.

I like the idea of being able to type rcf in the search box and have all the Right Click Framework packages appear.

I think the functionality of a package is more important to the framework it plugs in to. That said, I don't mind if extra stuff is shown somewhere that's searchable (like the "Get Info" stuff).

So we're agreed that standardized package filenames aren't necessarily a good idea? I think they are within an organization perhaps, but not in the community at large.

As far as naming convention. I'm selfishly concerned here about LAVA submissions. I would like to see all LAVA Code Repository packages have LAVA in the product name or the filename (or both). In addition to being installed beneath a LAVA category in the palettes or menus (if it's a tool).

I think it'd make more sense to have LAVA packages in a LAVA repository - then "LAVA" or "LabVIEW Advanced Virtual Architects" or "lavag.org" or whatever we want would show up in the repository field.

I think it's even more important to have *categories*, not name standardization. I can image the default view in VIPM getting pretty unruly once a few more packages are released.

For example, if I'm looking for some DAQmx stuff and I sort by package name " jgcode_rpk_ni_system_style_daqmx_controls-1.0-1" won't help me.

Out of interest I was wondering if the above Idea was ever considered to be a feature but got pulled? Does anyone know?

Yeah, and I'm glad it wasn't implemented - I think the absence of a key is more intuative than a green key.

Congrats mate - well done!

You should still bae able to edit the code (all your DAQmx VIs will be missing, but that's okay) - then when you load your VIs on the windows PC it should find the missing DAQmx VIs again (you'll obviously need to re-save the VIs once they're back on te Windows PC).

Bug?

"Big" is kiwi for "bug"

Actually, I think it's because you've opened the class outside of the exe context, and it can't find it's parent (or something else?) You're right though, when you run your exe it'll work just fine. I had the issue just recently, although I was loading a lot of related classes from disk (with different relationships), and, sure enough, as long as I did a source distribution of the parent, the icon was there. Either way, it didn't matter.

There's been some discussion over here about finding an appropriate place to distribute templates. Here's a summary:

Christian: it makes sense to put them alongside the existing templates.

jgcode: I would suggest storing them all relative, then placing it under user.lib/vi.lib (with a new namespace as per LAVA thread) with access via palettes for the API and Tools menu (or a wizard) to create templates.

crelf: When my packages include templates, I tend to have them with all the other package VIs, include them in the palette – but I make them merge VIs. This is much easier and more intuitive (IMHO) than putting them in the templates folder (which, again IMHO, no one uses anyway).

Christian: The challenge in this case is that the VI temrplate is not just code, but also UI components/colors and VI properties. Using the Merge VI option does not include these features when placing the code on a blank VI. Given the nature of this reference design I think this is too much of a limitation.

crelf: True – actually, merge VIs and front panel stuff don’t work well – I’m sure there’s a bug there (eg: make a VI with a few controls and decorations, then merge it = the controls vs decorations are offset). CAR #39212

jgcode: (the "New..." dialog) is pretty slow, but I thats the most logic spot for all my Templates that fall into the above category - and I use it all the time. If the dialog was cache'd between calls (with a Refresh Button and an IN for programmatic access) that would be better IMHO (another Idea). Additionally another Idea is to allow Templates in the Tools Menu - at the moment Templates are ignored. A fast way to access Templates would be just to select them from the Tools menu and a new instance would be created?

crelf: Sure, but if all the interfaces to a reuse package are in the pallete, then that's where I'm going to look for them. Having one component in the "New..." dialog and everything else in the palette isn't intuative IMO.

jgcode: What is your current workflow for templates at the moment? (As mentioned above I currently install into the <LabVIEW>\Templates folder). What do others do?

So, jgcode asked the question: what do others do?

jgcode: Additionally another Idea is to allow Templates in the Tools Menu - at the moment Templates are ignored. A fast way to access Templates would be just to select them from the Tools menu and a new instance would be created?

I wouldn't call that a big, but I'd sure like the ability to have templates in the Tools menu. Maybe make the suggestion on the LabVIEW Idea Excahnge?

There's also this from Matrix Consultants.

Regardless of which method you choose to store the data in the app (class, globals, cluster), persisting the data is fairly easy:

My version of the preferences dialog uses the OpenG panel to disk VIs, and they work great. I'll try to post an example tomorrow, if someone reminds me with a PM...

If a scaler (single string) is wired to the type input of the "variant to data" function, there are no errors. This could be caused because there is no data on the variant "value2".

Right - you're trying to read a single Excel cell into a 2 dimensional array - that's not going to work. Also, I'm guessing that there's an error on the error cluster after the convert to variant VI, which might be causing something downstream (prbably the Workbook|Close method) to not execute - that's why Excel isn't closing. I suggest you rearchitect your code a little to use the merge errors VI, instead of chaining all the errors into one wire.

...just take your preference file you created and rename/replace it with "prefPage_Colors.vi".

Oh Mike - that is just too funny My first LLOL of the day!

I think the plan will be to make a copy of all the necessary VIs (less than there are now), place them in a separate lvlib and install all the code in its own location separate from any VIs used by the LV IDE.

I think that's a great idea, aalthough I'd like to see it distibuted as a VIPM package so I can control my project-based configuration management.

Reusing the LabVIEW options (preferences) dialog framework to create your own custom dialog for your application, along the lines of crelf's use case, is fairly simple and I will post a couple of VIs and an example in a day or two that provide a wrapper around PreferencesDialog.vi and a slightly updated template to build your own options pages.

Excellent - I look forward to seeing what you come up with

(cant mark as solved or something on this forum, can you?)

Nope, but you can vote a post up by clicking the green (+) ball on the lower right of the post. LAVA is more of a forum than a collection of Q&A threads, so we didn't think it made sense to allow members to mark posts as specific categories (like "Solved").

Yeah, I don't think this is possible with what's exposed - sorry

Actually, you only need to click once

Is this a deployed application? If so, what were your language settings in the installer?

Are you looking to hire a consultant? If so, check out www.viengineering.com - we have a *lot* of engine and LabVIEW experience.

Brilliant! I remember doing a similar thing at college (physics), but with colors instead of sounds.

LabVIEW wouldn't be the same without you, and NI is a better company for having you - congratulations on making the 10 year mark mate!

I think that's a property of your avi player - try right-clicking on it in the ActiveX frame and deselecting "size with content" or something like that. Also, maybe upload an example (code + avi) that shows the issue - we can help better if we have that to work with.