Jump to content

Black Pearl

Members
  • Content Count

    410
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by Black Pearl

  1. 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
  2. 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
  3. Search for the 'Tunnel wireing wizard'. Felix
  4. 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
  5. 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
  6. 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
  7. everybody should get a low orbit ion canon (LOIC) and follow anonops. For the freedom!

  8. is trying to transform a vi into xml. Crazy?

  9. 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
  10. 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
  11. 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
  12. 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
  13. They are after you, even if you aren't paranoid. Felix
  14. You can address the vi's as if the llb was a folder. So the path would be MyFolder\MyLLB.llb\MyVI.vi Felix
  15. 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
  16. 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. 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. 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
  19. wrote a LV 3-way merge ;)

  20. 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
  21. 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
  22. 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 re
  23. 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
  24. 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 h
×
×
  • Create New...

Important Information

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