xcontrol boolean state default

[Mark_Holm]

I have made an XControl.  The State ability contains 3 booleans among other values.  One of the booleans, the first one I defined, is giving trouble.  Even though I set it True, and select "Make current value default" then "Apply Changes" then "Save", I can not get a Property read of the value to return True on the first attempt.  Also, program behavior that depends on this value does not properly default.  I have also checked that the default value for the "Read" property and the "Write" property that access this value are also set to True.  In the Init ability, I also can not get the three states to keep a True value in this item.

Something, somewhere has decided very firmly that the default value for this item must be False, and I cannot get it changed.

Any ideas?

[TCPlomp]

In your Facade VI, you should set the 'State Changed?' to TRUE.

I don't think the facade VI will look at the 'default' values for the front panel of that VI.

In you Init Ability you should set the value to 'TRUE'

Ton

[Mark_Holm]

The Init ability won't allow me to set the value in the Default Control State and in the Default Indicator State and Current State, it won't stay True even if I set it.  I expect that Current State might change depending on the last executed value, but the Defaults should remain as I set them (and I can't even set the Control Default.)

In the Display State Change event of the Facade, I change some other State values, and they seem to work OK, but there is no reason to change the value I am having trouble with there, that I know of.  It does change in a Property Write, which calls Display State Change.  That works fine.  The value just passes through in the Display State Change, I don't even unbundle it.  I is only used in another Property Write event, where it modulates the behavior.  It works as expected there too.  The only apparent problem is the inability to set it to a TRUE initial value.

[Mark_Holm]

Also, Display State Change Event does set State Changed and Data Changed to TRUE.

[TCPlomp]

Could you post your (complete) XControl, and mention the LabVIEW version you are using?

Ton

[Mark_Holm]

BTW, The other two Booleans in State seem to initialize just fine.  One is set TRUE and the other is set FALSE.  They seem always to start up with correct values when I read them via property reads.

[Mark_Holm]

Virtual Channels XControl along with a testing VI is attached in a zip file.  The XControl Files are inside a folder.  Using LV 2009 with the F2 Patch.

[SnowForest]

Hi Mark,

In init ability maybe you want be sure that you don't read previous state? You must edit case structure little bit(Wire default values to state). You can of course save a current state that you can read it in next time but that was not your point? There is also save ability to do that.

 Jim

[TCPlomp]

It's hard for me to reproduce, since I don't have daqmx installed.

Howeve you could try debugging your init ability by placint a break point inside the VI.

And you could inspect the variant from a previous run (if the owning VI is saved) with my Variant XControl.

Ton

[Mark_Holm]

I doesn't seem to be a matter of anything in the Init ability block diagram.  Rather, the problem seems to be that the whole Default Control State control on the Init ability front panel is locked, so that I cannot change the value of any of the controls it contains.  I suppose setting them programatically on the block diagram would work around the problem, but it seems a very ugly fix for a problem that is in the nature of a bug.  Really ought to fix the bug rather than doing a work around.

When I first wrote, I did not include (because, somehow I did not realize) that all of the Init Ability, Default Control State is locked.  It is.  The Default Indicator State is not locked.

As I interpret the purpose of the Init ability, the Default Control State and Default Indicator State values on the front panel ought to be settable, and persist, so that they are the correct place to put the default values.  Doing it on the block diagram would seem to miss the purpose.