Francois Normandin

I think that's what the function does behind the scene. A rectangle is simply one case of any number of geometries you can make with this function's inputs. NI Vision rotation algorithm is more complete because it will interpolate colours when the rotated pixel positions are not integers, but otherwise it's the same. The rotation matrix in 2D is exactly what you state above. Rotation of points.vi

You can limit your responsability by making the package to be installed on version = 9.0 instead of >=9.0... But then, you'd have to make a new package for 10.0 after you've verified the compatibility, and 11.0... and 12.0. I suggest you wait until it breaks.

Hi Pravin, Check in the Mathematics/Geometry palette. There is a 2D rotation matrix VI. (2D Cartesian Coordinates Rotation.vi) See this link for how it works.

Chris has been in the US too long...

Hi Jon, You typecast from LVObject to LVObject, so I'd expect that you don't get an error for that with "To More Specific Class" prim. I suspect there would be a significant increase in overhead if this primitive were to dynamically check for the class hierarchy when it's fed with LVObject. It seems to me that this is like a using the code below: <a href="http://content.screencast.com/users/normandinf/folders/Jing/media/7a120e9c-2ed5-448a-973c-9971c69993b2/class%20typecast.png"><img'>http://content.screencast.com/users/normandinf/folders/Jing/media/7a120e9c-2ed5-448a-973c-9971c69993b2/class%20typecast.png"><img class="embeddedObject" src="http://content.screencast.com/users/normandinf/folders/Jing/media/7a120e9c-2ed5-448a-973c-9971c69993b2/class%20typecast.png" width="452" height="249" border="0" /></a> While the other case is clearly wrong as expected. In my opinion, this is not a bug in the behavior of the primitive but perhaps a bug in documentation?

Or you can put a checksum in your file. Change a bit and they're screwed... (That should teach them some manners...)

You're right that it should be moved to a different thread. I'll ask the "Ultimate Forum Gods"... Edit: Dak, no problem. It's probably simpler to move than to merge ;-)

Thanks to our admins, it seems that the Forum Guidelines are back and in an easily found location. But there's a typo to be corrected: Guideleines and it got propagated (copied?) even in the Guidelines page... <a href="http://content.screencast.com/users/normandinf/folders/Jing/media/34073c59-5fcd-419a-b2d2-d65eb7a49e4c/2010-09-17_0837.png"><img'>http://content.screencast.com/users/normandinf/folders/Jing/media/34073c59-5fcd-419a-b2d2-d65eb7a49e4c/2010-09-17_0837.png"><img class="embeddedObject" src="http://content.screencast.com/users/normandinf/folders/Jing/media/34073c59-5fcd-419a-b2d2-d65eb7a49e4c/2010-09-17_0837.png" width="353" height="118" border="0" /></a> <a href="http://content.screencast.com/users/normandinf/folders/Jing/media/6977a39f-27d4-4193-82e0-5f78f2c49942/2010-09-17_0837.png"><img'>http://content.screencast.com/users/normandinf/folders/Jing/media/6977a39f-27d4-4193-82e0-5f78f2c49942/2010-09-17_0837.png"><img class="embeddedObject" src="http://content.screencast.com/users/normandinf/folders/Jing/media/6977a39f-27d4-4193-82e0-5f78f2c49942/2010-09-17_0837.png" width="325" height="303" border="0" /></a>

For datatype, Jon made good suggestions. For the styles, you'll need to create a look-up table. This "Style ID" will discriminate between System style, classic and modern... but I'm sure that the ID will change between Boolean, Combo Box & Numerics. If you want a universal look-up table, you should consider using scripting to create it: that's another question.

Good job Joe!

This is a good point, as almost all functions in this API are not available at runtime. It is meant to be a development tool. Perhaps it is Shawn's goal too?

Hi Shawn, 1) Oops. Totally unintentional. I'll swap the error inputs in next version and post a comment in the online documentation (known bugs). 2) Yes it comes from NI. I think it was posted on LAVA before the LAVA1.0 crash. Since scripting is released, you can do it without this password encrypted VI. Use the private method "Parent Class" and call recursively until you hit the cube object (no more parent references).

There is a private property for this, called Style ID. It's available with scripting. Here's a snippet.

You need to save it to disk first, then drag on diagram. It works on LV2009 too. I think it has to do with Firefox (or maybe the way LAVA deals with pictures?) because I've dragged them directly to diagram before. Don't sure what has changed since I did that.

Let me guess: Basic Object Flags? Did you get any "insane objects" when closing the VI before you stumbled on the right bits?

Thanks for the feedback. I'll make that a configurable option in the next version.

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,

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?

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.

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.

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.

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.