Francois Normandin

So now when you run the Control Generator program it always pops a File Dialog window asking to "Select a single PNG file or choose a source directory for batch processing", is this something needed for the new two image VISTA1 buttons, because otherwise the screen looks exactly the same as the older version I can't figure out how I'm supposed to add the second image?

The opening popup is set in the config.ini file as the source directory for the icons. It will always ask you which icon you want for the first control to be created. I assume you don't want to create the same icon as last time, so I made the program ask again everytime it opens. If that's annoying, that could be changed.

The Control Generator program is exactly the same. What I did was simply add the functionality to the class, not modify the Control Generator program.

You can use the Control.lvclass methods as shown in the piece of code attached to the same post (Create Different Decals for True False.vi). This VI allows you to automate your control creation but without help from the Tools menu. Not setting the "true state" icon will simply take the "false state" icon for both. That's the easiest way to add it to the class while maintaining the same functionality. The class can be found in the user.lib, under UI Tools palette.

You see, at the moment, I rely on the way the template is ordered to know which states are true/false/hoover. This is not satisfying to me, but a quick fix for your opening question. Let's say you take the Outlook style template, which has four different backgrounds (actually: true and false states + 2 x hoover states, one for true and one for false), so if you try the code I provided, it might mess up the true and false states and you'd end up with a true decal on your false hoover state (Haven't checked, but that's what I suspect might happen). I'll probably create a tag in the template or number them as part of the PNG naming convention for the templates to work correctly whatever the initial template style, that way I could modify the class to know which ones are true and false and that will stay transparent for the user. I still need to keep it compatible in case someone out there has already modified the provided templates and uses them. I don't want to break the code you created last year...

To make a long story short: until I have this functionality added in the class (and keep backward compatibility with the current versions), I will not make modifications to the Control Generator. (But you can if you wish, on your own copy... )

Hope this answers your questions,

No problems - I would do almost anything to help get this working

Chris

Hi Chris,

I don't run into such a problem at home either. It might be a good idea to close LabVIEW when upgrading from 1.0.15 to 1.1.3. Just in case that the code was copied but an old version of "Control Generator" or BitMan VIs were still in memory from a previous call. This shouldn't happen with normal dependencies, but this is a rather unusual transition. Prior to VIPM 2010, it was impossible to install a package built into a lvlib (namespacing issues), so it had to be added with OpenG Builder. Now that it works great in VIPM 2010, I think the way to go is either to include the BitMan code in my package with a different namespacing, thus copying twice the code if you already have BitMan in your user.lib ==> I don't like that use case; or the following procedure (just this once, for the transition between the OGP to VIP package):

- Uninstall UI Tools: Control addon 1.0.x (*.ogp)

- Make sure BitMan is removed from user.lib (unless it's been installed with the package from Vugie)

- Close LabVIEW

- Install BitMan's package (unless already installed)

- Install UI Tools: Control addon 1.1.x (*.vip)

- Open LabVIEW

See if the linkage is OK.

As mentioned, I don't have this problem either on XP or Win7 with multiple LV versions installed. It must be that some code from the LabVIEW 2009/Project folder gets loaded in memory and keeps an old version in memory somehow. I think these VIs (in Tools menu) are loaded in memory into a separate application reference. Could that be it?

Something weird is happening......

It works OK on my work computer.

You know what, let me check tonight on my home computer... that's where I usually build my packages. I've put a question on VIPM's forum about an auto-dependency that I've never seen before... it might be a symptom of the weird stuff you see (or not). Anyway, yet another reason not to put this in CR. Sorry that you have to be my beta-tester!

New version posted with proper dependency for BitMan.

It's for 2009 and up. When saved properly on 8.6, I'll update the code rep with latest version.

I just installed it, and it seems to delete some of the Bitman files. It's fixable by installing Bitman again afterwards, but I expect this shouldn't happen.

Yes, I used to check for the installed BitMan and install it if not already there. At this point, if you installed BitMan using UI Tools v1.0.15, it would be uninstalled when you upgrade. That's an error I did yesterday when I built this temporary package. I'll fix that now that BitMan has been made as a package and will deprecate the other packages. I was afraid I had missed something, so that's why I didn't commit the code to CR. Stay put, I'll have a fix soon.

What would be the effect (on the data) of transformation. I guess nothing:

Ton

Yes, that's what I meant. Transformation = no buffer copy. Interpretation = copy of data in buffer to type cast.

I see your point.

I think you'd have transformation is you went, for example, from U8 to U16 (padding)

and reinterpretation for DBL to INT where you'd have a complete reinterpretation of the value because DBL is stored as exponent and mantissa, while integers are "pure" hex values.

Check out this page and you can guess which and reinterpreted.

Hi Francois,

Thanks for all that effort, but I seem to be having some problems installing this new version (1.1.0.1) over my current version of 1.0.15-1 using VI Package Manager 2010.

When I finish installing the new package (all OK) and then select the Control Generator from the Menu it goes looking for the BitMap.lvclass - which I think? this new version removed from my LabVIEW directory. I've got the zipped up BitMan Library do I just stick this whole lot into the <userlib> folder?

Chris.

Unzipping in user.lib would work. My error was that previously to VIPM 2010, I used OpenG Builder to add the BitMan files as a post install step. Forgot to port it to my new vip file.

I asked Vugie yesterday if he was willing to make a VIPM package out of BitMan to add it as a dependency and he did it already. Again, I'll add this in a new package as soon as possible, with the correct dependencies.

In the meantime, install BitMan's package and you should be fine. (or unzip from your archive into user.lib)

Alright Chris,

here is a temporary package. I won't put it in the Code Rep yet because it's saved in 2009 and I'd like to port it to 8.6 to keep compatibility with the last package in CR.

I've tested the Control Generator in the Tools menu: no changes that I could see. It seems to work as expected. Then there's an extra VI that I didn't include in the package but that you can find here below.

lava_lib_ui_tools_control_class_addon-1.1.0.3.vip (>= LV 2009)

Use this VI as an example for creating controls with different pictures for True and False. It's hardwired to use the Vista1 template.

Create Different Decals for True False.vi

Hope this helps you.

Except perhaps the occasional need to automate a few tedious tasks if we find ourselves in a lax minute or 2..

That's what "programming" is all about, isn't?

Just got the email this morning I passed my CLA exam at NI Week 2010.

I set this goal a while back so I happy to have achieved it - this is from one of my first posts on LAVA:

Awesome!

Even with no lucky charm sitting close by... I'm sure you'd have nailed it anyway.

Ideally I'd like an event generated after each control is updated.

I'm afraid that probably wouldn't work. A user could change a control, then walk away with the mouse still hovering over the control. Then it wouldn't generate the mouse leave event.

In this case, it would only be a matter of time before a user changes the control, then forgets to push the go button. Then I'm getting a late night phone call wondering why the furnace was set to 210C is only running at 200C.

Try this one. I set the filter to 1000ms.

event_multiple click.vi

You'll need to adapt it to multiple controls.

However a nice guideline would be to use the LAVA category as the main category and then you can put your branded category as a sub-palette of that if you like.

So if I hear you correctly, you mean that the LAVA palette should be restricted to Certified LAVAcr code. Right?

Personally, I would adhere to a package naming convention if it existed. That being said, best practices take time to emerge because best practices have a lot to do with how comfortable people are with a well know concept. Has there been enough water flowing under the VIPM bridge to make it obvious what the best practices are? Probably, but it doesn't mean that everybody "has to" adhere to them to build packages. I think it'd useful to have a few "examples" of how one can name a package, just for the sake of all the occasional package builders out there. Just like design patterns, there are no "one size fits all", but a few helpful recommandations might be in order to get newbies started with a decent naming practice. After all, we've all been beginners at some point and would have liked to find a forum or wiki with a lot of helpful topics... Oh wait, it exists already!

The above-mentioned idea to have a LAVAG icon in the palettes to put all the LAVA stuff is gonna have more momentum, I think, simply because it's easy to implement and doesn't mean everyone needs to follow the rule. I wouldn't put my code under a JKI palette because well, I'm no JKI! But a LAVAG palette? Yeah, I'm a LAVA for sure... so it's as good a place to put it as any other.

Hi Vivante,

there is no documentation on XNodes because this is unsupported technology from NI. Start by reading about it on the LabVIEW Wiki.

Hi Francois,

First I'd like to say that the Control Generator Tool is the best thing since slice bread - it saves sooo much time - Kudos^infinity.

I'm not sure though if the tool can create a VISTA1 style button with different images for the TRUE/FALSE states + keep the Hoover effect?

Thanks for the kind words.

I hadn't thought of this use case when I put up the Control Generator Tool.

I created a VISTA1 button using the Control Generator and then tried to add another image for the other state in the LabVIEW Control Editor, however it seemed to distort the cross image and I lost the Hoover effect.

Am I just doing this wrong or should I instead use your Control.lvclass tools to do this programmatically?

I haven't tried, but I suspect that you get a distorted image because the button image you introduce is not the same size and something gets resized. I didn't create these buttons with vectorial images, so they don't resize well. The Hoover effect loss might just be that you customize the button by pasting directly over the "depressed button" and this would overwrite the hoover state. The Vista1 buttons are created from a 6-state system button template (72x72 pixels) and the hoover state is the 4th state (if I remember correctly).

So for this to work manually without distortion and keeping the hoover effect, as quickly as possible, you would need to:

1- Create a button with your False state decal.

2- Create a second button with your True state decal.

3- Open the second button with the "Customize Control" editor (the usual Right-click Advanced >> Customize...)

4- Hit the "Switch to Customize Mode" button. Right-click on your button and select one of the depressed state picture (true state). Copy to clipboard. Close this button... you can even delete it from disk.

5- Open the first button with the "Customize Control" editor (the usual Right-click Advanced >> Customize...)

6- Now copy the clipboard image on all three states that represent depressed states.

7- Apply changes and voilà, you have a new True state decal with the same size (no distortion) and with hoover effect.

I have made a video but I seem to have a nasty microphone problem and without audio, you might just as well follow the above mentioned steps.

Well here it is anyway:

<object width="425" height="344">

<param name="movie" value="

<embed src="

</object>

However, you surely want to do it programmatically. At the moment, it can't be done because the "Preview Control States" VI messes with the button states even if you change them using the Properties VI provided with the API (I'd definitely call that a bug in my implementation). I was able to do the modifications in a few minutes to the existing class. It requires adding a True State Icon, modifying the Read and Write Icon PNG VIs and modifying the Load Icon & Preview Control States VIs. I'll prepare a new version soon and post it here. Stay posted and thanks for the feature suggestion.

Here is the error I get when I drop it (v1.2.0.3) in VIPM 3.0.

Any idea why?

Hi Antoine,

You MUST have VIPM 2010. VIPM 2010 can now install packages anywhere on disk but it comes at the expense that packages built with 2010 and not readable with earlier versions. Once you move your package to 2010, can't go back.

The good news is that anybody can now build unlimited VIs in their packages with the community edition. Some goodies are reserved for Pro edition, but it's gonna open up to a lot of people.

Sorry, I guess I should have written this in the readme. (DONE)

Yes that looks really good!

Ton

It's online. v 1.2.0

Maybe I misunderstood the OP. I thought he wanted the name of the class and the names of its ancestor classes not the complete hierarchy of a class, that is, not including its children (descendants).

He mentioned using a dynamic dispatch method, so this up the chain hierarchy would be determined at run time.

Did I miss the objective here?

Kurt

You understood it better than me. Now that I read it again (and your answer), I agree with you. Thanks for pointing this out.

I am not familiar with RT, but can't you use the Get LV Class Path vi and parse the name from that? Call your parent node vi and have it do the same thing? Each parent could append an array or append a string until you have a complete list?

I can make an example if you need.

Kurt

The "Parent Class" property requires that you open a reference to your library (refnum, not object), which you can't do at runtime, so RT is excluded too.

The Get LV Class from Path primitive works on RT, but the hierarchy can only be found, as stated by AQ in another thread Mike mentioned, through hacking the XML. But this solution has not been posted yet, to my knowledge anyway.

Thanks again. I "abused" your library to get the LVClassLibrary.ParentClass which I was unable to find in the menu.

I hope you don't mind...

Br, Mike

Certainly don't mind...

For your RT problem, you might want to keep the hierarchy in a text file. I remember reading about that here on LAVA where people had the same problem. If not mistaken, Antoine Châlons discussed it. (Might be wrong, but try looking for his posts.)

Thanks, I'll take a look, but what do I do with a VIP file?

Br, Mike

Download VIPM from jki.net. It's a code reuse package manager. Very useful to distribute code, get code from others and keep track of all your own reuse code, with forward portability between versions.

If you don't want to install a third-party software, PM me and I'll send you a code example.

I would really like to get the name of the LV class and do this for all its ancestors.

So it will by a dynamic dispatch method that should return all the class names back to the base class.

HI Mike,

take a look at this API. And find attached the latest version* I use.

There is code for getting the class hierarchy (array of refs or array of paths).

*Disclaimer:

This version 2 of the API is not in the Code Repository yet because I haven't ported it back to 8.6 and haven't retested all methods, so use at own risks. But between you and me, the code for hierarchy is safe.

I also changed the package naming convention since version 1, so you might get a palette conflict if you have both installed at the same time. It might go back to what it was, but most likely, I'll just change the place where the code is stored and where it's installed in the palette to be able to install both. Version 1 becoming "deprecated" simply because I'd rather call it lavag_lvclass_api than normandinf_lvclass_api...

lava_lib_lvclass_api-2.0.0.15.vip

But I wonder how many other people I annoyed?

Make a poll? Auto-flagellation is always fun to watch.