meaning of black border on object icon?

[PaulL]

What does a black border on a class (LVOOP variety) indicator mean? (Usually the border is gray, as in the first example, but sometimes the border is black--see the second example. I vaguely remember reading somewhere what this means, but I can't remember where.)

[Tomi Maila]

QUOTE(Paul_at_Lowell @ Dec 11 2007, 07:11 PM)

What does a black border on a class (LVOOP variety) indicator mean? (Usually the border is gray, as in the first example, but sometimes the border is black--see the second example. I vaguely remember reading somewhere what this means, but I can't remember where.)

I think it means that the value of the class constant differs from the class default value.

[Aristos Queue]

On the front panel, it means the control/indicator has a default value different than the class' default default value.

On the block diagram, it means the class constant has a value different than the class' default default value.

[shoneill]

QUOTE(Aristos Queue @ Dec 11 2007, 08:32 PM)

On the front panel, it means the control/indicator has a default value different than the class' default default value.

On the block diagram, it means the class constant has a value different than the class' default default value.

OK, this is something I've wanted to do myself actually.

How does one actually create multiple constant instances of a Class with different content without creating a new Class?

Shane.

PS Sorry for the thread hijack....

[Tomi Maila]

QUOTE(shoneill @ Dec 12 2007, 10:21 AM)

How does one actually create multiple constant instances of a Class with different content without creating a new Class?

At least in LabVIEW 8.5 you can copy a value of a class control or indicator from right click menu and then paste it to a class constant, control or indicator.

[shoneill]

QUOTE(Tomi Maila @ Dec 12 2007, 09:40 AM)

At least in LabVIEW 8.5 you can copy a value of a class control or indicator from right click menu and then paste it to a class constant, control or indicator.

Thanks Tomi,

So you take a snapshot from a "live" class (with different data as the default).

Is it possible to manually set the values of a constant? I can do it the first way, but manually would be more comfortable.

Shane.

[Aristos Queue]

QUOTE(shoneill @ Dec 12 2007, 05:17 AM)

Is it possible to manually set the values of a constant? I can do it the first way, but manually would be more comfortable.

No, it is not only not possible, it is explicitly worked against (The reasons have been discussed elsewhere in the forums; look for posts from Jason Dunham). All paths to setting the value of an object are through the object's programmatic interface; you cannot construct an object by any means other than running a VI. This comes close to guaranteeing that all values of the class conform to limitations imposed by the class' API and no internally inconsistent objects exist. (The one path to an inconsistent object is to create an object, make it the default value of a constant, and then edit the VIs so that the constant value is no longer one that could've been validly created. There's nothing I can do about that case.)

PS: Please use the term "object" for an instance of a class. Your posts above talked about having to create a new class, and that really confused me. You create a new class once, and then you create objects of that class type. It'll make the conversation clearer for all of us.

[shoneill]

QUOTE(Aristos Queue @ Dec 12 2007, 06:22 PM)

PS: Please use the term "object" for an instance of a class. Your posts above talked about having to create a new class, and that really confused me. You create a new class once, and then you create objects of that class type. It'll make the conversation clearer for all of us.

Correct.

first post: "How does one actually create multiple constant instances of an object with different content without creating a new Class?"

second post: "So you take a snapshot from a "live" object (with different data as the default)."

I'll try to remember that in future.....

Shane.

[Guillaume Lessard]

QUOTE(Aristos Queue @ Dec 12 2007, 11:22 AM)

All paths to setting the value of an object are through the object's programmatic interface; you cannot construct an object by any means other than running a VI. This comes close to guaranteeing that all values of the class conform to limitations imposed by the class' API and no internally inconsistent objects exist.

Very good.

Now why is it so hard to make a class probe? The reason we have the knee-jerk reaction of wanting to see object contents as a standard cluster is that it's rather painful to see the data. It's feasible, but it's a lot of preliminary work for someone who is just trying to learn LVOOP and understand what's going on! Helpful code-generation tools are needed! =)

[Aristos Queue]

QUOTE(Guillaume Lessard @ Dec 12 2007, 01:36 PM)

Very good.

Now why is it so hard to make a class probe? The reason we have the knee-jerk reaction of wanting to see object contents as a standard cluster is that it's rather painful to see the data. It's feasible, but it's a lot of preliminary work for someone who is just trying to learn LVOOP and understand what's going on! Helpful code-generation tools are needed! =)

The generic probe for an LVClass does show the data as a cluster.

To create a custom probe for a class, just popup on any class wire and create a new probe using the probe wizard, same as you would for any data type. You may want to add the new VI to the class if you want to directly access the private data in the probe.

What aspect would you want simplified? (Note: I'm not disagreeing with you that it could be simpler. I'm asking what specific tools you're looking for.)

[Guillaume Lessard]

QUOTE(Aristos Queue @ Dec 12 2007, 01:22 PM)

The generic probe for an LVClass does show the data as a cluster.

To create a custom probe for a class, just popup on any class wire and create a new probe using the probe wizard, same as you would for any data type. You may want to add the new VI to the class if you want to directly access the private data in the probe.

What aspect would you want simplified? (Note: I'm not disagreeing with you that it could be simpler. I'm asking what specific tools you're looking for.)

The part where a new probe doesn't automatically add itself to the class is quite irritating in itself; having to dig for it, move it, and then convince it to be part of the class... honestly I find it quite an energy barrier! Also, popping up on a class wire and creating a new probe there is not exactly intuitive -- seems like a pre-LV8 way to do things. Why not have the option of creating a probe VI directly from the lvclass/project window? (In a related gripe, creating and editing the mnu file for a class pop-up palette is also too circuitous). Should have the option to create "probe" and "palette" in the same menu as "static dispatch VI" and "dynamic dispatch VI".

I'll stop here, because my LV machine is not in running condition and I can't compare wishes with reality. I'm sure I could come up with suggestions if I sat in front of it and thought about improvements; right now I mostly just remember that I was frustrated with the process of writing a probe!

[Aristos Queue]

QUOTE(Guillaume Lessard @ Dec 12 2007, 06:59 PM)

Why not have the option of creating a probe VI directly from the lvclass/project window? <snip> Should have the option to create "probe" and "palette" in the same menu as "static dispatch VI" and "dynamic dispatch VI".

Curiously enough, no one has ever made this suggestion before. It's a good idea.

QUOTE

(In a related gripe, creating and editing the mnu file for a class pop-up palette is also too circuitous).

I can't help with this one. I don't get involved in palette editing. The palettes are the single most commented upon aspect of LV. Everyone has an opinion about how they should work that is 100% unique from all other LV developers, and almost everyone is pissy that their idea isn't taken as "well duh". I get involved in palette UI only under extreme duress.

[Guillaume Lessard]

QUOTE(Aristos Queue @ Dec 13 2007, 01:21 AM)

Curiously enough, no one has ever made this suggestion before. It's a good idea.

Well, then. I guess I'll try to make suggestions more often!

[TerryS]

I was scanning VIs that were recently resaved to exclude compiled code.  Then I did a scan of all VIs that their compiled code was indeed removed.  I would open a reference and then check the property.

Opening a reference to some files would crash LabVIEW (though they open from within their lvclass and run).  I noticed the black border as something these VIs had in common.  Anyone come across this?