control reference on cluster element perverted in run time execution mode

[thorgal]

OK, so know that we know that it is reproductible, would NI people tell us what they plan to do to correct this bug? or if at least they have monitored this thread.
😉

[Ben]

THe thread is to deep.

Repost the example with the details and examples and make sure declare it a BUG!

That will get someones attention.

Ben

[Greg_McKaskle2]

> OK, so know that we know that it is reproductible, would NI people
> tell us what they plan to do to correct this bug? or if at least they
> have monitored this thread.

While this forum is a good place to discuss things, it is not as good at
being a bug reporting service, as the bug reporting forms on the NI web
site. NI developers and support engineers are always lurking here, but
the best way to report a bug is to send in a good description perhaps
with an attached VI.

As for how it will be fixed? It is hard to tell until you get to the
bottom of bad code.

Greg McKaskle

[Andrey_Dmitriev]

>While this forum is a good place to discuss things, it is not as good at
>being a bug reporting service, as the bug reporting forms on the NI web
Greg, why not?

But, of course, I sent this bug to NI too (I think, not only), and now official answer from National Instruments. I think this information not secured and important:
-------------------------------------------------------
This is not a bug.
Control captions are lazily created. (That is, when you create a control, it does not have a caption. When you select the Visible Items>>Caption menu item for the control for the first time, a caption is created.) When you read/write any capton properties, if the control does not have a caption, one is created in the development system. However, in the
built application, we cannot create new objects. So if you read/write a caption property and if a caption does not exist in the built application, the property node returns an error... we returned error 1054 (The specified object was not found). You must create these objects in the LabVIEW development system), which we hope is more informative.
-------------------------------------------------------
But my opinion, that this is a small "documented" bug, because visibility property and object presence - two absolutely different things. If object invisible - it means, that object is present. If caption doesn't present, in context menu something like "Caption-Create" must be appear. If I can create this object, why I cannot delete this object? Note, please, that for object creation RUN is enough. Where information, that new object was created? Where information, that file was changed? I think something incorrect in this logic. But now this behavior described by NI.

[Ben]

HI Andrey,

I read Greg's response as saying that this list it not a good place to look for a fix.

I still it is a grewat place to discuss and clarify.

One of the things that seperate humans from animals is wqritten language. Using this we can learn from the experience of others that we may never see or meet. No animal is capable of this feat.

This forum facilitates this type of learing. Until they toss me on the street, I intend to continue to look for these types of discusions and welcome others brining these issues to the fore.

Ben

[Greg_McKaskle2]

> why not?
>

Why is this forum less effective at reporting and investigating a bug?
Or why is this effect not a bug?

Let me focus on the second item. Several items in LV panels are lazily
created. Captions, graph cursor legend, and graph scale legend are
created when shown in order to keep from bloating panels for the
majority of users who do not use them. This is a good feature, but it
can be represented in a number of ways. At the moment, it is not made
obvious that this is going on, and LV simply creates the objects when
needed. The problem you are seeing is that once taken to a runtime
system, where objects cannot be created, this behavior has to change.
The current runtime either grays out or leaves the items out of the
Visibility menu and the diagram nodes return an error.

As mentioned, this could be changed to make it more obvious in the
editor, but that will not change how this behaves in the runtime. The
runtime is incapable of creating objects to keep its size down. Down
the road we would like to make the runtime more modular so that you
could install a module allowing for creation of objects when needed, but
leave it out in the applications where you do not. Until something like
this is possible, I think the best solution is to document this
limitation rather than clutter the interface with more menu items.

About the first issue. The developer zone is definitely useful for Q
and A. It could possibly be the primary resource for bug reporting, but
there are a few problems with this. The LV portion of devzone is also
the usenet group comp.lang.labview, which is how I'm accessing it at the
moment. Probably the best reason though, is because that is how NI is
set up. Ideally, devzone acts as a great resource for troubleshooting,
but once you believe you have a definite bug to report or fail to solve
your problem with devzone, please use the support channels pointed out
in the manuals and on the web site. If you have recommendations as to
how this can be improved, please pass it along to those channels as well.

Greg McKaskle

[Greg_McKaskle2]

> I read Greg's response as saying that this list it not a good place to
> look for a fix.
>
> I still it is a grewat place to discuss and clarify.
>

With the risk of beating this in the ground. This forum is all about
discussion. My point was that bugs should be reported as is requested
in the manuals and on the web. DevZone and info-labview are great Q&A
forums, but not so good for filing bug reports to NI. This is a public
forum, so do what you like, but for best results in filing a bug report ...

Greg McKaskle