Jump to content

Dev Toolkit


Recommended Posts

Hey there,

I have a project that currently holds template VIs (and their supporting VIs) for use by developers in developing new applications for a system we've been working on. Now I'm trying to wrap this up in the best way possible into a launchable "toolkit chooser" that creates a new project with the chosen template and the supporting (probably in a lvlib) VIs, ready to be saved to any location the developer so choses.

I have some kick-off questions, after researching ways to go about this:

1) The Getting Started Window (GSW) seems to be an ideal place to stick the link to the Tk chooser. I've been successful in inserting new items into the LV8.5+ GSW and am pretty comfortable about being able to launch pretty much anything I need to launch from here. For some reason though, inserting a new item in the "new" section pushes the "open" section MRU list down and mangles the "target" dropdown. Does anyone know how to shorten up the MRU area (dynamically would be ideal) so this doesn't happen?

2) Has anyone ever messed around with the "Copy To/From Project" private methods? It looks like they should give me what I need, but I haven't been very successful in using them.

3) Is there any way to programatically invoke that new nifty Project "Save As..." feature so I don't have to "roll my own"? It would be nice to have all the toolkits in their own project files ready to go...and just invoke a Project Save As.... based on their selection so they could chose where to save it and what to name it.

4) Let's say I want the Tk to open up a project from disk (remember, this is from the GSW...so there aren't any active projects open) and programatically pick and chose what I want to copy out of a project on disk into a new project in memory (without saving it yet). I could launch a VI which asks which toolkit to use, then opens up the project on disk, creates a new project in memory and copies stuff over...closing the original project after it is done. Is there any way to ensure that no changes are attempted to be saved to the original project on close? What I mean is, even if I make the template project read-only, there may be a chance that closing it may generate prompts to save changes. I don't want that...

5) Is there a better way to do this?

Thanks for any insight!

Link to comment

QUOTE (orko @ Apr 5 2008, 12:23 AM)

Does anyone know how to shorten up the MRU area (dynamically would be ideal) so this doesn't happen?

Build your own GSW window. Eyes on VIs from Christina has a lot of info.

QUOTE

2) Has anyone ever messed around with the "Copy To/From Project" private methods? It looks like they should give me what I need, but I haven't been very successful in using them.

No, only the add.

QUOTE

3) Is there any way to programatically invoke that new nifty Project "Save As..." feature so I don't have to "roll my own"? It would be nice to have all the toolkits in their own project files ready to go...and just invoke a Project Save As.... based on their selection so they could chose where to save it and what to name it.

I don't think it is avaible, I think it calls a sequence of functions.

What you could do is have every TK VI in a lvlib in a separate folder. If a LVLIB is selected, you do a save as on the lvlib, copy it and the directory, add the lvlib to the new project and you should be save.

QUOTE

Let's say I want the Tk to open up a project from disk (remember, this is from the GSW...so there aren't any active projects open) and programatically pick and chose what I want to copy out of a project on disk into a new project in memory (without saving it yet). I could launch a VI which asks which toolkit to use, then opens up the project on disk, creates a new project in memory and copies stuff over...closing the original project after it is done. Is there any way to ensure that no changes are attempted to be saved to the original project on close? What I mean is, even if I make the template project read-only, there may be a chance that closing it may generate prompts to save changes. I don't want that...

I think programatically closing a project will close it, without saving changes.

QUOTE

5) Is there a better way to do this?

Dunno.

Good luck,

Ton

Link to comment

One item to be aware of about the GSW that Christina's blog doesn't mention... if a user has modules installed (RT, FPGA, etc) those modules will add items to the GSW and change the available space for New / Open / MRU, etc. There are three different backgrounds that the GSW can have depending upon the modules installed, which change the number of items allocated to each region. Be aware of this. If you post to Christina (use the feedback section of her blog), she can probably get you an image of the three backgrounds and describe when each one is used so you can plan accordingly.

Link to comment

QUOTE (Aristos Queue @ Apr 6 2008, 09:30 PM)

There are three different backgrounds that the GSW can have depending upon the modules installed

Thanks AQ, I knew of two versions of the GSW (with/without the Targets section) but didn't realize there was a third... I've asked Christina for her help on this.

She also mentions in her blog that the GSW isn't a supported feature in LV8.5, and as such may change in future revisions (read:use at your own risk). I was wondering if there was any changes to the GSW in LV8.5.1, but after reviewing the readme I don't think so. That was a bug fix release... so I would think that changes(if any) would probably be more likely to occur in a minor release (ie:LV8.6).

As far as the whole "template/tookit chooser" that I'm trying to accomplish, I was also wondering if someone at NI would have had some insight on the mechanisms used internally to create new target projects (like the RT/PDA target projects that are created on the fly after their wizards finish). Are those just using VI Server calls to the Project API to create new projects in memory based on the user's choices in the wizard? That was my plan of attack for this custom project creator that this is turning out to be. :)

Link to comment

Currently, you can't add items to the GSW. You can only replace them. That's because I haven't written anything to make the background dynamic.

So you're going to have to remove one of the existing items in whatever section you want your new link to appear.

The multiple backgrounds Aristos mentions won't help here. There are three (Windows w/o Target modules, Windows w/ Target modules, and Mac/Linux) backgrounds because the Targets ring and the Search bar are only shown with Target modules and Mac/Linux, respectively.

Link to comment

QUOTE (orko @ Apr 7 2008, 12:05 AM)

As far as the whole "template/tookit chooser" that I'm trying to accomplish, I was also wondering if someone at NI would have had some insight on the mechanisms used internally to create new target projects (like the RT/PDA target projects that are created on the fly after their wizards finish). Are those just using VI Server calls to the Project API to create new projects in memory based on the user's choices in the wizard? That was my plan of attack for this custom project creator that this is turning out to be. :)

It's just VI Server calls to the Project API to add files, however, it's a little more complicated when adding targets. You might find resource\Framework\Providers\lvdesktop.llb\PC_New.vi useful. Pass it your project reference and the project's "Root" reference (to the "Item" input). The "BehaviorGUIDs" input allows you to restrict the displayed results. The RT and PDA project wizards for example would use known BehaviorGUIDs so that the dialog only presents supported target types. I'm not sure how liberal we are about giving out GUIDs and such and I unfortunately don't have a list of all the possible BehaviorGUIDs anyway, but some other LV person (or PSE) who trolls here might be able to help you more with that particular input. ;) After invoking that VI, you should be able to continue operating on the project refnum by adding files to your new target with VI Server. If you're dealing with shared variables, be aware that much of their VI Server interface is private, but there is a primitive VI-based API in vi.lib\variable\* that might help.

Good luck!

Link to comment

QUOTE (Christina Rogers @ Apr 7 2008, 04:55 AM)

Ah, Ok. I think that limitation is going to invalidate my reasoning for trying to integrate into the GSW. :( I was trying to add an item/task without taking away anything that the developer had access to originally.

So perhaps the next option would be to try and use the "New" dialog, which opens when you either select the "New" or the "more..." link on the GSW. I'm looking through the code (what I can see...a lot of the GSW library is locked) and I understand how to place a new node into the LVNewDialog.xml so that my item shows up in the Project category. Unfortunately, I don't see a built in MagicNumber (yes, I found out where these come from :ninja: ) that will allow me to open a copy of a project into memory from a "template" on disk. The only built in way to get this to happen that I see is to use the elaborate "Project from Wizard" mechanism, which the more I delve into the more I realize it is way too complex for me to follow blindfolded.

I feel like I may be flailing here. The task seems easy enough, copy a project from a disk location and open it up in memory as a new unsaved project. Unfortunately the method to do this doesn't appear to be part of the GSW or its plugins (even though it seems really close).

QUOTE (bpreis @ Apr 7 2008, 12:09 PM)

It's just VI Server calls to the Project API to add files, however, it's a little more complicated when adding targets. You might find resource\Framework\Providers\lvdesktop.llb\PC_New.vi useful. Pass it your project reference and the project's "Root" reference (to the "Item" input). The "BehaviorGUIDs" input allows you to restrict the displayed results. The RT and PDA project wizards for example would use known BehaviorGUIDs so that the dialog only presents supported target types. I'm not sure how liberal we are about giving out GUIDs and such and I unfortunately don't have a list of all the possible BehaviorGUIDs anyway, but some other
LV
person (or PSE) who trolls here might be able to help you more with that particular input.
;)
After invoking that VI, you should be able to continue operating on the project refnum by adding files to your new target with VI Server. If you're dealing with shared variables, be aware that much of their VI Server interface is private, but there is a primitive VI-based API in vi.lib\variable\* that might help.

Now this may be something I can use...! Thank you for your insight...and the tip on shared variables, although for this project we aren't using them.

One question, do you know when this became available (LV8.x)?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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