Jump to content

Black Pearl

Members
 View Profile  See their activity

  • Posts

    410

  • Joined

  • Last visited

  • Days Won

    13

 Content Type 

Posts posted by Black Pearl

  3. Reuse, Packages and SCC

    in Source Code Control

    Posted

    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.:thumbup1:

    I'll post back when I've done some more testing.

    Felix

  5. Reuse, Packages and SCC

    in Source Code Control

    Posted

    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

  6. Reuse, Packages and SCC

    in Source Code Control

    Posted

    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

  8. [Discuss] quick create a new vi from template

    in Code Repository (Uncertified)

    Posted

    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

  16. Calling LabVIEW.exe from another exe

    in Development Environment (IDE)

    Posted

    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

  17. Calling LabVIEW.exe from another exe

    in Development Environment (IDE)

    Posted

    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

  18. Calling LabVIEW.exe from another exe

    in Development Environment (IDE)

    Posted

    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

  21. Hook into Save VI?

    in VI Scripting

    Posted

    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.

    :oops:

    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. :ph34r:

    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. :book:

    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 :beer_mug:.

    Felix

    • Like 1

  22. Hook into Save VI?

    in VI Scripting

    Posted

    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

  23. Hook into Save VI?

    in VI Scripting

    Posted

    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

  24. Hook into Save VI?

    in VI Scripting

    Posted

    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... :ph34r:

    So far our best idea was a global hotkey-assignment of the Ctrl+S key via AutoIt.

    Felix

×
×
  • Create New...

Important Information

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

  I accept