[LVTN] Code Capture Tool

[Ton Plomp]

Yair is correct, working on Password protected BDs is kinda difficult. For instance what should happen with the block diagram after capturing? Should it lock?

There is some code for that purpose, but I think it's removed from the current stable revision.

Ton

[asbo]

On the code repository page for this tool, the download link lists two files: Code_Capture_Tool-2.1.4-1.ogp and Code_Capture_Tool-2.1.4-258.zip.

Are these different releases? I don't understand why the ZIP file is marked -258 when the package is marked -1.

[Ton Plomp]

Both files should install the same code-base.

The mark 258 is the actual SVN revision used for the build. I haven't incorperated that into the OGP builder

Ton

[asbo]

If you don't mind the suggestion, adding an 'r' prefix to the revision would make that very clear. Thanks!

[Antoine Chalons]

While trying VIPM 2013 on mac I noticed that CCT is not MacOS X compatible (at least not with LV 2013) can you modify the appropriate setting when building the package's next release?

 

or better, make the next release MacOS X compatible :-o

[Yair]

What exactly is the problem? I'm not well versed in the VIPM package build settings and I know nothing about the Mac, but as far as I know, the CCT should in principle work on the Mac. I know that we wrapped all the platform specific code so that it would. Is it just a matter of setting a flag in the package to mark OS X as a supported platform?

[Antoine Chalons]

The Code Capture Tool GUI__CCT.vi has a broken arrow, the LLB <vilib>:Utility:inputDevices.llb isn't found, I think this llb is Windows only.

 

 

I'm running LV 2013 beta, I have no other LV version to try at the moment on my mac.

 

 

Is it just a matter of setting a flag in the package to mark OS X as a supported platform?

 

 

 

yes, I think that by default a package supports all plateforms but you can set restrictions.

Here's what it looks like :

 

Edited May 8, 2013 by Antoine Châlons

[Yair]

the LLB <vilib>:Utility:inputDevices.llb isn't found, I think this llb is Windows only.

 

Yes, as far as I know that's true. As far as I can tell from my memory (and your image), that's the part of the code that handles the panning and zooming of the preview image. I believe originally this used only events, but I guess from the label that Ton added zooming with the mouse wheel, which wasn't supported with the event structure. I don't have the code in front of me, but I see no reason in principle why this code can't be moved to a dynamically called VI, thus making it compatible again.

 

I'm not sure when it will happen, because I don't currently have access to the CCT repo and I don't even remember which version it's currently in (7.0 or 2009). If you happen to want to make the change, I'm sure it will make it likely to go faster.

[Antoine Chalons]

I'll try that, thank you for the suggestion.

[Ton Plomp]

Hi Antoine,

 

Yair is right that code is used for the panning/zooming using the scroll wheel. I always thought that code was OS generic.

Can you place the whole while loop + init/close VI inside a conditional structure, to see if it is fixed then?

If so we can easily create a platform limited code for Mac/Linux.

Apparently this code is only available on Win/Linux.

 

Ton

[GregSands]

But with this idea In Beta, perhaps there will be a built-in solution (I don't have the 2013 beta so I can only speculate on what might be coming).

[Yair]

But with this idea In Beta, perhaps there will be a built-in solution (I don't have the 2013 beta so I can only speculate on what might be coming).

 

We have platform and version specific features in the CCT by placing them in dynamically called VIs. In principle, it would be possible to support scroll-zooming on non-Windows platforms in LV 2013 or later by wrapping the code in such a call, but it would require several VIs to support the various platform and version combinations (probably Win <2013, Non-Win <2013 and >=2013).

[Antoine Chalons]

Hi Antoine,

 

Yair is right that code is used for the panning/zooming using the scroll wheel. I always thought that code was OS generic.

Can you place the whole while loop + init/close VI inside a conditional structure, to see if it is fixed then?

If so we can easily create a platform limited code for Mac/Linux.

Apparently this code is only available on Win/Linux.

 

Ton

Ton,

I also had to remove an event case from the VI called "Annot_Deamon__CCT.vi" because it was using the Mouse VIs. Then it works fine

[Ton Plomp]

Filed as issue  #22

Fixed in version 3.2.1, that is available at SourceForge and the Lava Code repository. Should go live shortly on the LabVIEW Tools Network.

It's fixed by placing the Mouse VIs in a conditional case structure that's only run for Windows and Linux.

 

Ton

Edited May 23, 2013 by Ton Plomp

[Jeff Bohrer]

Cross post from the NI Forums.

Small glitch with CCT of selected FP

[Yair]

Cross post from the NI Forums.

Small glitch with CCT of selected FP

 

A quick test seems to indicate that this was resolved in a later version of the CCT. I didn't dig into what was actually going on, but I saw the problem in one LV version with an older version of the CCT and I didn't see it on LV versions with the newest version from the tools network (3.2.1).

[Jeff Bohrer]

Previous issue resolved with upgrade to CCT 2013.  Mega Kudos Yair!

Trivial request for additional space for just-in-time advice.

[crossrulz]

I finally started really using LabVIEW 2013 and have repeatedly ran into a problem with the CCT.  I load the CCT and create a snippet.  The snippet is successfully created.  However, then the tool starts to save the 271 CCT VIs.  It seems to pause at VI 258 and then closes.  With previous LabVIEW versions it would save the VIs the first time exiting the tool.  But 2013 is always trying to save the VIs.

 

Windows 7 64-bit (in case that matters at all).

[Yair]

I'm pretty sure I installed the CCT on the 2013 beta and didn't have this problem. I suggest you open the CCT caller VI (should be under LVProjectLAVA and it should be set to auto run) and look at the code. IIRC, it checks the top level VI for mods and uses that to trigger the save and because it's saved last, it never saves it and always sees mods.

 

I'm assuming that what's happening here is that it's probably stopping on an error or propagating it and then not reporting it. You could probably simply put a breakpoint after the save VI method, then call the CCT and replace the breakpoint with a conditional probe and wait until there's an error to see which VI the problem is in and what the problem is. One possibility is that you don't have access to save one of the VIs, but that's just a guess.

[Jeff Bohrer]

Cross-post from NI Forums http://forums.ni.com/t5/LabVIEW/How-can-i-change-the-background-of-labview-front-panel/m-p/2696525#M801184

 

Code Capture tool ignores Pane Background for Front Panel.  (Minor, but notable)

[Yair]

Cross-post from NI Forums http://forums.ni.com/t5/LabVIEW/How-can-i-change-the-background-of-labview-front-panel/m-p/2696525#M801184

 

Code Capture tool ignores Pane Background for Front Panel.  (Minor, but notable)

 

It's not the CCT, but the Get Image method. I reported it to NI a few years ago (gave them the link to this), but I have no idea if they did anything with it.

 

It might be possible to get the background image using some properties and then apply it ourselves, but I doubt it would actually be possible (since you have to somehow draw it BEHIND everything) and I don't think it would be worth the effort even if it was possible.

Edited January 15, 2014 by Yair

[Jeff Bohrer]

And while we are waiting for Edit>>Create snippet from selection to catch up to the CCT.... 

 

Let me preface this with my most common use case for creating snippets-  Discussion forum posts.  I even keep a menu shortcut handy since I post so dratted often.  Ctrl+/ (Who needs to tile windows anyhow?)

 

Ah, but tools>>Lava>>CCT isn't "menu shortcuttable"  or whatever the term should be.  And if it was, like Create snippet from selection, it would need to be aware of the context.  Try Tools>>Lava>CCT... from project explorer...Ctrl+/ doesn't do anything, it is discarded, the CCT correctly chastises me for invoking a tool in a foolish manner.

 

Which gets me into areas of LabVIEW I really don't play with ever.  I suspect a QD shortcut would be a more approachable route to create code capture of selected (Or All) Block diagram by running a vi with the appropriate CCT API calls.  Ideas from the experts are more than welcome.

[Yair]

I don't know about menu shortcuts, but the QD option should be fairly simple. First, I seem to remember some discussion about this in the QD group a couple of years back, so you can try looking there to see if anyone did anything.

 

Second, if you look at the CCT launcher (in <LV>ProjectLAVA), you'll see that all it really does is get the VI ref and give it to the CCT. Since QD already gives you the VI ref, all your plugin needs to do is call the CCT VI and pass in that ref, and I expect it should work then. Seems easy enough.

[Jeff Bohrer]

Thank for the advice Yair.  I'll look at it this weekend and let you'all know what I found out

[Darin]

Shameless plug

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Keyboard-Shortcuts-for-User-Items-in-Tools-Menu/idi-p/1190221