Francois Normandin

Ah, indeed.

I should probably make a new version of the expansion packs instead, which would install them in the vi.lib/addon directory.

Expect the correction in the next version.

thanks.

Update...

To add the addons under the "LAVA>>UI Tools" palette, I've needed to create a UI Tools palette package that will install through LVTN. My submission has not been done yet for this addition, so it will be a while longer before I post an update for the Tree-Tagging addon. Failure to do so would cause multiple UI Tools palettes to appear side-by-side in the LAVA palette, which is terribly bad style . The good news is that is works well and will allow me to integrate more addons that way in the future.

I'll be reviewing all the comments I got on this addon, make modifications and tests, and I'll submit it whenever I'm through with the LVTN submission. Since your solution works in the meantime, I'll leave it at that for now.

Hi Stobber,

I refactored the UI Tools but not the addon modules yet.

I'll check to see if I can get a new installer to change the location of the palette of these addons.

thanks for the feedback

And here is the first draft. I'll add this version into the next update I post on LVTN.

If this is not what you expected to get, please send me more feedback and I'll happily oblige to give more details.

Putting this up made me think of a few more functions I'd like to feed into this tool... that should fuel my next update with more ideas.

UI Tools Help Document.pdf

Hello Bob,

[sorry for the late answer: I was on vacation]

you're right that I should put together a more comprehensive help for these functions.

I'll work on it and come back to you. By the way, version 1.3.0.70 is available on LVTN.

Perhaps in the meantime you can check the implementation I made of the UI Tools addon: Control Class.

There is no more documentation on this toolkit, but it is a more intuitive API specifically created for creating controls. It requires the UI tools to run.

http://lavag.org/files/file/120-ui-tools-addon-control-class/

I'm refactoring this addon to make it available as well on the LVTN shortly, but that's still in the pipeline. I promise to make a better documentation out of this one as well.

Thanks for the feedback.

Just got the approval for attending this year.

Now that the all-important BBQ ticket is bought, it's time to check for hotels.

It's been discussed that having a typedef in the private data of a class is not recommended because of class mutation history...

Would I get the same problem if one of my class member is an event with a typedef'ed enum as its datatype?

The typedef'ed enum is not part of the class [edit] private data[/edit]. The event is not a typedef.

What will happen to class mutation history if I add an item to my enum in a future version of the class?

I've had the same kinds of flickering problems with this particular ActiveX. I remember I hooked to the Event Callbacks and deferred panel updates until a particular action was completed. It was not an overlay but rather a resizing problem that caused the ActiveX container to resize to the original video size and then back to the "fit to screen" in a fraction of a second. I couldn't get rid of the effect but this was a workaround that worked in my case. I don't know if such an approach could help in your case...

This one might be of interest also...

<resource\plugins\templatebrowser.llb\NewDlg GetActiveProject.vi>

I think it is a fault, but it would be desired behavior for transparent subpanels.

I just remembered AQ wanting to be able to click through a transparent subpanel. It's almost funny that the right-click works the way he wants but not the left-click...

I hadn't thought about the fact that I use "Pane:User Menu Activation" vs any other object directly. But it doesn't seem to be the culprit. It behaves actually as if I had made the subpanel with "transparent background", which it is not.

Ravi, thanks for the workaround. For now, it will do just fine.

Is there a way to have the VI running in a subpanel catch the right clicks (User menu) instead of the parent VI?

A right-click on an empty subpanel returns "SubPanel" for the SubObj class name.

When a subPanel is loaded, it will return the subpanel's control/indicator class. However the "User Menu Selection" event will run in the parent VI. Anyone knows a way around that?

You can change the feedback node direction and wire the output of the node instead of the output of "+1".

That would be the equivalent to the case structure.

Definitely plausible.

I think it's clear it's a situation to avoid, but just for the sake of understanding, why would there be a difference between in-project and out-of-project VIT?

Honestly, this is the first time I use a VIT file for instantiating VIs. (Probably first time I save a VIT file altogether!)

I naively thought I'd put my "template" in the Getting Started Window where I could call it with other templates... Isn't that what templates are all about?

Of course I'll put this VI has a "Drop VI Content" icon in the palette and will never use the GSW template... but that's not the point.

I had a perfectly working VI and when I saved it to a VIT file, I tested it one more time before packaging it and noticed it was slow on first generation calls. And by slow, I mean 3300ms! (200ms for the stripped down VI I posted above).

Copying an entire 184kb VI in memory should not take 3.3 seconds. If there is something potentially going wrong under the hood, I think it's my responsability to point it out for further investigation by the experts. Then again, it might be perfectly normal. I would not even have noticed a 200ms delay in launching the async VIs.

And frankly, I never heard of anything like "don't use VIT files anymore, they're useless". If it is an official message, then it hasn't been heard.

OK.

I get 1ms accross the board (even 2011f2). This is just loading it straght up and running. However. Add the file to a project, dbl click and run-> 256 ms.

Yep, I confirm this too on my machine.

Well, this is mostly for understanding how it works under the hood, because a VIT file is not intended to run as a main program, unless in Development environment.

It's gonna end up in a palette with "Drop VI Content"...

I'll send a support ticket just to know if that's a bug or expected results like suggested by James.

About time you put in a capital req for a new PC

Looks like Crossrulz has the best computer after all.

About time you put in a capital req for a new PC

He's still faster than on mine.

Thanks Shaun. Perhaps I should restart LabVIEW.

Edit: I'm on LV2011 (no SP1) 32-bit.

I was updating a reuse template of mine for asynchronously calling itself to simulate as an example for inter-process communication tests.

It took me some time to find out what was causing the first level to be slow. It seems the culprit is the reference to the VIT file.

The stripped-down template below (LV2011) launches a clone of itself everytime we press the "Launch Async" button.

Async Launch of VIT.vit

You'll notice the time required to open the reference is immensely larger when you click on the first copy than on any others.

And it scales rapidly with VI size. My full template is 184kB and takes 3.3s to load the reference. This one is 20kB and opens up in ~200ms.

Simply changing the extension to .VI solved the problem.

Is there anything I'm not doing correctly? Should this be considered a bug or a feature?

Edit: Added a small video on Jing... http://screencast.com/t/aN29fYxJw3A6

I thought the VI was way too simple to upload, but hey, here it is .

Reproduce Pane Background Property Bug.vi

Edit: CAR # 347359

When there are multiple panes on a front panel, the pane background image will return the image of the previous pane when empty.

EDIT: CAR NUMBER 347359

Done. Looks like it's been abused for close to 4 months.

Since the site is not maintained anymore, I don't know if the admin can make the front page un-editable?