Jump to content

Black Pearl

Members
  • Content Count

    410
  • Joined

  • Last visited

  • Days Won

    13

Posts posted by Black Pearl

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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
  8. 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

  9. 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

  10. 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

  11. But then you realize that you just have to right click and select TortioseSVN->Revert to solve all your problems ;)

    Question: do you automatically check in vi's when they are saved?

    Normally I work on a bunch of vis together and close (so save) them, but just check in the bunch together (including callers if recompiled) when a task is done.

    As a side node:

    I'm currently working on a large uml project (well, I'm working my way through the specs, so I guess I'm at 100+ classes) and Eclipse/Papyrus is crashing pretty often. :throwpc:Yesterday it managed to destroy the main model file. :frusty:Then I discovered that there was a build-in revision control, so I could revert to my last save (and due to the crashes I save often).:worshippy:

    I'm not sure if there is a hook for saving/closing vis, but having them automagically commited to a SVN repository with a auto-message could be cool. Then of course not use SVN but Hq for multi-users so the check-in is only into your private repo and not breaking the build.:book:

    Felix.

  12. You can make this by-val as well. What you need is a bi-directional association. So you need a container of Sensor and Power Meter in each class (somewhere you propably nee to use the parent clas + type cast). When you transform PowerMeter to Sensor, you just place the PowerMeter Obj in the Sensors property and then returen the Sensor, and the other way round.

    Edit: Search for 'Beagle State Machine' for this birlliant design.

    Felix

×
×
  • Create New...

Important Information

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