-
Posts
410 -
Joined
-
Last visited
-
Days Won
13
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Black Pearl
-
-
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
-
- The contained VI "lv_new.vi" destroys the file, "New..." dialog. And it looks like it is not needed. (It took some time to restore the original file...)
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
-
1
-
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
-
I try to update the recent files menu when I perform a hq rename + 'Save Instrument', so I get the old name deleted and the new name added.
Any ideas?
I tried the ini file, but it seems to be read on startup and written on shutdown, so I need some call into the App.
Felix
-
Using procmon is fun. I found a lv_subvi.vit. Boah!
Well the first hint was googling for lv_quit.vi; I found a server where I don't have access to (but somehow I got some google-hit which displayed the line). It seems to be some lego toy library. So anyone who has a kid at that age, please search for these files on your kids PC.
Well, any attempts to use it resulted in a crash.
I thought I could upgrade my old 7.1 to 2011.
As another dark alternative, I found some obscure ini keys that give access to some internals. First let's me load but not modify some menus, I think it's the the real IDE menus. The second one gives me all the 'dialog' that show up but are not present as a vi. Well, they just consist of the FP, the terminals are not connected. Wonder if I could place some code there.
Anyhow, I'll need to setup a sandbox to mess around with this.
Well, lesson learned as young novice of the black magic. Feed that google-engine the right keywords, and you get access to too many secrets you shouldn't know.
Otherway round: if you need to keep a secret, fear big brother google.
For the historians, there is an old lava mailinglist out there in cyber space
.
Felix
-
1
-
-
Using procmon I found a hook that seems to have been overlooked so far:
lv_quit.vi
It's a bit difficult to get this working, as if you close it's FP, it just get's called again. I propably need to rename the file programatically to allow LV to shut down...
Furthermore it's called after the the close, so Menu Activation VI returns an empty string. As I don't know if the vi was saved before the close, I can't directly use the MRU list.
But propably I could use it to send triggers to a background service...
Felix
-
Ben: I'll look into this
ShaunR: I'm on FDS, so I don't get the SCC menu.
But the point is very interesting. If you look at the default menu (all is tested unter 7.1 only), you get the tools (project folder) menu and the help (?) menu listed, but not the wizards folder (which inserts between new and close). The AppBuilder can be seperatly purchased to the FDS and is inserted at it`s own unique place in the menu. I'm unsure about all this, because private property nodes already allow you to check if you have an AppBuilder. So it might be hardcoded support in the LabVIEW.exe and/or there are hooks.
vugie: there is a 'modified' boolean. This is my worst-case attack to monitor this for all vi's and if it's going from true to false, I know the vi has changed and was saved. So then I would poll the mod.bitsets as well and commit on flag down with a comment of these bitsets. But I dislike the option of a constant polling background service.
Felix
-
I'm working on integrating mercurial/Hg into the LV IDE.
At the moment I have a nice menu entry called Save & Commit. Well, that's a understatement.
1. Check the mod bitsets of the vi
2. Save the vi
3. Commit the vi with user defined message
4. Add the mod.bitset in human readable version to the commit-log.
It's some really nice automgic I have running right now. However it requires the user to select the menu entry. Using save or closing a vi and then saving (saving subVIs) is resetting the mod.bitset. And that would be the really cool way of having it integrated, all vi's that are only changed due to a recompile are marked as such, hence you can ignore them in a merge!
So what I wish to have is a hook or hack into the Save procedure.
As usual, I'm open for black magic, dirty hacks (redirects of dll calls), scripting background services and the like...
So far our best idea was a global hotkey-assignment of the Ctrl+S key via AutoIt.
Felix
-
Funny, I noticed the same thing and was planning to post it tonight.
Propably being not able to access lava made us all crazy and using google and twitter and all that modern things...
Felix
DLL Error Handling
in Calling External Code
Posted
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