Francois Normandin

Thanks for the update. I heard so many things (rumors, rants) about Disney's copyright legal enforcements that I can understand they're a little frigid...

The front and back are not the same, although they are similar. I'll wait for a confirmation by Chris before completing the form again...

I agree. I never found the property to change the frame color programmatically. I think it's not exposed... otherwise I would have colored it red to indicate there was something hidden...

There seems to be a slight problem... My order was cancelled because the design supposedly contains copyrighted material. See excerpt of email received from zazzle:

If you don't have VI Analyzer toolkit, see if this can help you. With scripting available, we can now definitely build analysis tools of our own. Test_CheckAutoGrowOff.vi (LV 8.6, requires OpenG Rectangle tools)

Don't upload the manual just yet... But maybe some word about the multimeter model and an upload of your code would be a good start.

Are you sure? I'm on 8.6 too and it works.

This is what you should get. But it works only for objects beneath the structure, not hidden inside but out of sight.

Your signal to spam ratio is still good in my opinion...

That must be the hWnd in other languages. By specifying "0", it's effectively the same as "null" is text languages, thus creating a new one. Under Windows, it's "h" for handle... I guess it is called "host" to be more cross-platform.

Yes, with Tables you can do it by selecting directly with the cursor, no need to do it with the Edit Position property programmatically... Anyway, it showed that the MCL's behavior had a bug... you can never know when you'll have to add this functionality to an existing framework for which you can't easily replace the MCL with a table. Glad you found what you needed.

If you have a limited and well defined number of possibilities (0-5 for example), you could use a text-ring control. You have to set the strings values from 0 to 6 and then it will go in circle when you increment or decrement. If you have a huge set of possibilities (or infinite), don't try that. jcarmody's solution is what you need.

It's inelegant, but if you defer panel updates and change colors using {-2,-2}, and then select row header and column header successively to set them back to previous color, you shouldn't see the screen flicker and the user will not see the difference.

Indeed, I have been using MCL. But in the past I have also written code where I want the user to write a script that I will have an engine to execute automatically. Now, an MCL can do that too, specifically with a good use of drag n' drop from a list of commands, but it is easier in a text string to let the user edit parameters without double-clicking and opening yet another pop-up. In such a case, I would have wanted to parse the string and color it the way a Python editor would (for example). It's not optimal to have to rewrite the whole string font scheme everytime you drop a new command.

If I were ironic, I would say the goal is to increase the number of friends you have so that they feel good about increasing your reputation. One doesn't want to be friends with lame people without a good reputation, does he/she?

I've started a new thread because I think it's a bug. But let's hear what the others have to say about this: it could be intended behavior. To answer you problem directly, I think it has to do with the fact that whenever you append a string, the whole string will revert to it's last color setting and dump all font color info you've set. Follow this link to get a hint at what I'm saying.

Following up on this question, I've been wondering if this behavior is a bug or an intended feature and would like your opinion. Personaly I think it's a bug... but I might be biased by the end result I'm trying to reach. The issue is that when one uses String.TextSelction.Start and End properties to change the font of a string subset, it works as one should expect. But as soon as you append a string to it, the whole string text reverts to the font of the last property set instead of just adding the text at the end and keeping the fonts for the rest of the string. To better understand, try out the VI below. I've deliberately added a delay to allow for more dramatic effect... I can see why this "bug", if it is one, would be tough to get rid of. It has implications in how a string constant/control/indicator works. For example, if the font color from index 7 to 14 is "blue" and I insert a string subset at index 10, then it should follow that the text I insert would be "blue" also. The current workaround is to read the fonts of all characters in the string before appending/inserting and to rewrite each fonts after the operation, to restore the colored lines. It is nice when working on short strings, but imagine a log system with hundreds if not thousands of lines, all different colors for informations, alarms, data, etc. Even with panel update differing, it would be time-consuming... Change line color LV85.vi Change line color LV86.vi

And quite a newbie too... Congrats!

The bug has been confirmed by NI. CAR#178213

Hi Krystian, I checked and I confirm this. I would consider this a bug since the "Edit Position Property" detailed help says this is settable when the VI is running, it's a read/write property & the description explicitly says to use -1 for row or column header. Have you checked if this bug has been reported yet? EDIT: I posted this on the dark-side

Name: Password_class Submitter: LAVA 1.0 Content Submitted: 04 Jul 2009 Category: LabVIEW OOP LabVIEW Version: 8.5 Version: 1.1.0 License Type: BSD (Most common) Potentially make this available on the VI Package Network?: Undecided Copyright © 2008, François Normandin All rights reserved. Author: François Normandin -- see readme file for contact information website: www.monpapyrus.net/LabVIEW/index.html Description: Class for management of password objects. The object contains a MD5 encrypted password. Methods are of two types depending on source of password. From non-encrypted or encrypted sources. All vis are documented. There is an example VI that shows how to use encrypted & non-encrypted versions. Encryption level provides a mean to recursively encrypt many times over, resulting in better security against rainbow tables attack. Initialize once with Password_Create method. [Non-encrypted source] Source is from a dialog box or equivalent. The password is not encrypted at the moment the object is created. Password_Create method will create a new object, encrypt the password and store it. [Encrypted source] Source is from a file or tcp-ip connection. The password is already encrypted at the moment the object is created. Password_CreateEncrypted method will create a new object and store the password. Dependencies: Uses the following OpenG toolkits: oglib_md5-1.6-1 GOOP3® OpenG: <http://wiki.openg.org/Main_Page> GOOP® Community Edition 2.5: <http://www.endevo.se> Change Log: 1.0.0: Initial release of the code. 1.0.1: Readme modifications 1.1.0: Added encryption level and modified naming convention for dynamically accessible methods. Click here to download this file

Name: LVClass API Submitter: François Normandin Submitted: 03 Jul 2009 File Updated: 15 Sep 2010 Category: LabVIEW OOP Version: 1.0.2 LabVIEW Version: 8.5 License Type: Creative Commons Attribution 3.0 Copyright © 2008, François Normandin All rights reserved. Author: François Normandin --see readme file for contact information. Description: This code is provided to help manage labview classes. By opening a reference to a lvclass file, this API allows easy access to Private Data Cluster, Description, Class version, Icon, Tags, Class Items List, Ancestor Hierarchy, Addition and removal of files to the class, Copying and saving classes. It can be the basis for cloning a class, applying standardized icons to all VIs in the class, accessing tags and descriptions or to follow different versions. Dependancies: oglib_file-2.8 Change Log: 1.0.0: Initial release of the code. 1.0.1: Correction of installer code (second copy operation reversed) 1.0.2: Expose "Element (Build)" to Connector Pane in "IncrementClassVersion.vi" Known Bugs: 1- The "Close.vi" uses a merge error with the first error from a close reference. This will discard any error on input to the VI if there is an error from the close reference. Click here to download this file

It could be an issue with Invision's program. This version has been beta tested for about 6 months, but so do all versions of Windows.