Black Pearl

Sorry, but to boring... Actually, my file manager plainly told me what a vipc file is. I leave this to the readers to 'hack' on their own. In the end you have little more than you already get from OpenG Package Builder. Well, this 'little' prevents me from creating vipc files (I'm not sure if this was intended by JKI), but since ogp's install the same way I don't care. So back to the big picture of reuse. It's not done with creating a reuse library, but you need to make it damn easy for others to use the reuse library. That's where the team at JKI did put in all the effort for VIPM (which I think is worth the money). That's why I want my vi's in the palette (see earlier in this discussion). So I better invest my time on thinking: how can I make it easy for my team to use the reuse lib, what are individual concerns, habits and dreams on code reuse. For the installation of reuse code on the developement machines, VIPM community will be the best, because it's professional looking and easy to use. Creating snapshots, I think about a simple wrapper around the OpenG package builder's core, that just displays a small dialog: 'All your vi's from the reusable library are sucessfully added to your repository. Do you want to see the details? -> NO'. On the other hand, I think it's easy to create a small 'Installer' (there used to be a 'OpenG Commander' which was the predecessor of VIPM, so propably most code is already written). Then I can just get the snapshot in the user.lib/.. for field testing without the need to install LV2009-RT and VIPM. Felix

jgcode, is this a manual process relying on the discipline of the developer? So after update, do apply the vipc. Before commit, capture a snapshot? After all, the vipc format isn't really complicated. So I should be able to write my own snapshot tool in a day... Felix

Ok, as expected, there wasn't any issues using VIPM 2010 to install the *.ogp on 7.1. So the remaining question is, how to ensure the packages in the project are in sync with the packages installed in the LabVIEW folder. I see two possible sources of corruption: * I use a different (newer) version of my user.lib/subPackage and forget to update the packages in the project * I use a completely new package and forget to update the project both sadly would corrupt the repository. Any 'best practices' or even preferred automation options to deal with this? Felix

What about using a second application instance? I haven't done this, so I'm not sure how easy this would be. But then the 2nd App.Instance would crash and your main App.Instance would get errors when calling it, which you can deal with (recover). Felix

VI-Scripting is always only in developement (edit mode) only. There is a non-locked version in the lava code repository (CR), the versions posted on NI forums were password protected when scripting wasn't public available. Felix

If it were my decision, surely I'd run with LabVIEW PDS 2010 + SSP and VIPM Enterprise. I did already read some posts that described the use of package repository and this is exactly what I would like to have. As far as I have tested, the latest VIPM community is still able to connect to LV 7.1 and can read the packages I created with the OGPB. I didn't test if they get installed properly, but I suppose so. I'll post back when I've done some more testing. Felix

Search for the 'Tunnel wireing wizard'. Felix

jgcode, you nicely explained what I had in mind. The problem I have with VIPM is that packages created with it are only LV 8.2+ and I'm stuck with 7.1. So I'll see how I can implement the features I miss using the hooks provided by the OGPB and Hg. Paul, it's definitive that I need the palettes. Part of the reuse process is, to make it easy (for you and others) to use the reuse library -> easy access. And 7.1 has no project explorer. Felix

I'm planning to put a process in place for managing reusable code using mercurial for SCC. My old approach (using SVN) was to have the user.lib under SVN. This was ok as I was the only developer accessing this reusable library. Now I would like to share it with others in my team (using OGPB and VIPM community). Also this became a bit difficult as I started using other locations as well (instr.lib, plugins, tools...). So I was thinking about having the code-base seperate. Primary code would reside in a dedicated reuse-project folder (managed by Hg). Then I'd create packages using OGPB. These packages can now go onto a server for team-sharing. I as well as others would then install the packages in the user.lib and other places using VIPM community. So here would be the first question: ? How to track the version on a project basis ? I've been playing with the subrepositories feature in mercurial (this is suggested as analog to SVN-externals). But that would only allow the files to stay in the project folder, not in user.lib. The same issue with this use-case: ? How to get reusable checked out on the USB thumbdrive ? I found that Hg makes life easy there, as I can clone my repository for field-testing on customers side. If I install mercurial on the machine, I even can get the changes committed and back in the home-base, I just push what I've done to my developement machine. But I not really want to install VIPM (and LV2009RT) on the customer machine and have my reuse code deployed there. It's more effort than I save by having all nice palettes. This is also a problem with my current SVN approach. But here I did use source distributions with OGB and had a tool to check them back in the project folder. For both issues, I was thinking of a tool that would just pack all VIs that do not reside in the project folder and maintain a flat copy (e.g. zip archive) in the project folder. But this of course leads to relinking problems (which is generating a lot of changesets in the SCC). Another idea would be some kind of dynamically linking of the LV-IDE locations (user.lib and palette; instr.lib) to the project dir's, if possible. That would allow for subrepositories (and in this case I'd distribute via Hg instead of VIPM). Felix

Everyone still on SVN? Using Hg, you get a GUID (4 words Hex), that identifies the code (a branch in any repo somewhere). Thats more acccurate in a branching enviornment than the current rev. And then just make the 5.0 a shining decoration without real meaning. Felix

Hi shb, I did try to implement your suggestions. All ref's are now closed properly. Concerning the issues when switching to another app, I did try to use the private VI Activation event (therfore I labled this a 'beta release'). Seems to fire once in 7.1, but twice in 8.5. Is it possible for you to test this in other versions? I propably go the offical way and implement it with polling tomorrow. But anyhow, you can download V0.9.2 and test if this matches your use case. I'm still a bit unclear about the Esc-key. Ctrl-N, Ctrl-Esc should not create anything? Concerning VIPM, I failed making a package for 7.1. I'll try with the OpenG package builder if time permits. Well, over the holidays I will have enough time for this and some new tool. Felix

In 7.1. I have a private method (Application) called CompareVIs. This throws error 1043 on my FDS with the message stating: Not supported in this version. You need the PDS... ... or write your own LV_Differ. Felix

Ooops, sorry. That is the 7.1 "New ..." dialog that accidentially slipped in the zip. I'll try to find some time this weekend to play with your other suggestions (VIPM is planned since some time). Felix

I'd use uml and/or my soldering iron. But even if NI would disappear, LabVIEW will still be there, just no new upgrades/versions/bug-fixes. And support will be LAVA-only, which wouldn't be a bad option. Felix

They are after you, even if you aren't paranoid. Felix

You can address the vi's as if the llb was a folder. So the path would be MyFolder\MyLLB.llb\MyVI.vi Felix

Use PropertyGetCallData for a control. Use the properties dialog (right click on the control on the FP -> properties), then run the vi. The output returns the indices. Felix

Well, I'm stuck with 7.1 FDS. Felix

The winAPI calls didn't help. But strangely this did the trick: Uncheck 'Hide when LabVIEW is not active'. (the window is floating, not modal as I wrote above). It's not really perfect, als the hg-mergelauncher slipps in when the MergePlugin.vi was open when I started a merge. But this isn't the normal usage, so forget about it. Wonder if I get more of these issues. I think that LV isn't playing to well with gtk on Win. Felix

I moved my code in the LV enviornment calling the vi from the exe. (otherwise I couldn't call BDWin.Open). I am using VI:FP.IsForemost and App:BringToFront. My merge menu is modal and is on the top, but Hq stays before the vi's to merge. Haven't seen this effect that another app can place it's window between the LV windows. As soon as I click on the merge menu, the vi's are placed in front of Hq. I'll give the OS-call a try. I'm already so much relying on Win with this code. Felix

I've done a simple merging tool for Hg. Hg is needing an executable. This executable (of course coded in LV) is calling the LabVIEW.exe via VI Server to open the vi's (local, other, base, output) to be merged. Here my open issues: * If LabVIEW isn't open, Open Apllication Ref is returning an error. Is there a more elegant way of starting LabVIEW than using System Exec? * How can I bring the LabVIEW.exe (or the opend vi's) to the front? Application.BringToFront didn't work (without error). Currently The opened vi's are behind my merge.exe and the hg repro browser. Felix

Thanks AQ, so I don't need to try the dialogs. Using Close Panel? was among my first attempts. The events only get fired if the vi is running. Also I can't register if the vi is broken. Felix