LVOOP Class Process Data Bug?

[JeffOverton]

Hi everybody,

  Not sure if this is an actual bug, but I didn't see it posted anywhere.  I created a really basic LV Class with some private data members and some data access VIs.  Then, when I renamed one of my data members, the name did not and would not propagate to the VIs.  I tried saving, closing, reopening, changing and using Apply Changes before saving, everything I could think of, but a bundle or unbundle by name in any existing or new VI would show the old name of the data member.  I ended up deleting the data member and inserting a new one with the new name, and that finally propagated the change to the VIs.  I'm in LV8.5 on XP, and they were all inside case structures (error checking), so I don't know if that has anything to do with it.

  Is this an existing bug?  I'm sure I'll run into it again, and I'd rather be able to rename my data instead of having to delete it, add a new data point, and reorder everything.

Message Edited by JeffOverton on 11-24-2008 02:30 PM

[Ben]

---

JeffOverton wrote:

... I created a really basic LV Class with some private data members and some data access VIs.  Then, when I renamed one of my data members, the name did not and would not propagate to the VIs. ...

---

Let me try to understand (not that I am capable, since I am a self-taught LVOOPer).

1) Yo uused the "Create Accessor" option from the clas to create the accessors?

2) Once those are created they will not change if the value name changes, so this is where thing are not goinf as you expect?

3) If you go to the project and find the VI that is the accessor you want to change and select  (in side the project ) Save As...  does that work?

Ben

[JeffOverton]

1.) I right clicked on the LVClass object at the top of the tree (it's not in a project yet, but the project window looking thing that classes show up in).  Anyway, after rightclicking on (in this case) MFC.lvclass and selecting New->VI, I created basically the same thing as the Create Accesser option.  The only reason I did this is I can't bring myself to trust auto-code.

2.) I did not know that the lack of auto-updating was expected behavior, so that probably eliminated my bug question.

3.) No, this does not update the names.

If expected behavior is that member names don't auto-update, then I am seeing expected behavior.  I guess the new question is "Why is something so inconvenient the expected behavior?"

edit - oops, by the way, thanks Ben

Message Edited by JeffOverton on 11-24-2008 02:48 PM

[Ben]

"Hold the bus" (Rowen and Martin's Laugh-In)

I just want to make sure we are talking about the same things.

If you change the names of the fileds in the class data then the Bundle/Un-Bundle by names should adapt to the new name.

THe accessors of those fileds should not automatcially adapt. When you get to the point where you are doing "over-ride VIs" then you will see that changing the name (or its protection, or its icon connector) of a VI in a class is not something that should be done with much care.

Still trying to help,

Ben

[JeffOverton]

Ok, allow me to use some visual aids.  If I go into my class control definition, and change a member name here.

Should the name change here?

Message Edited by JeffOverton on 11-24-2008 02:59 PM

[Ben]

I just double checked (in LV 8.6) and yes change the filed name does propogate to the bundle by name* so ....

DISREGARD MY PREVIOUS since I was answering a Q you did not ask.

THe only explanation that I can offer for what you are seeing is (border-line insulting to say but I am trying to offer help, so brace yourself). That is the control NAME and not the caption you are showing, correct?

*To check the above:

Opened LV 8.6 project.

Found private data for a class.

changed "data" to data1" and closed private class data.

Opened a VI that accessed that field. the name had changed.

Another thought...

There was a bug where LV was not progating cluster name changes correctly and the recomended work-around was to make sure all VIs that used the type def were CLOSED when the the type-def was changed. This differs from the old way (pre-LV 😎 where it was better to have all callers open when the chage was made.

Sorry about the confustion! I'm just trying to help,

Ben

[JeffOverton]

Ok, even with the MFC.ctl as the only LabVIEW file open, no changes are propagating.

I've attached the class stuff if anyone with 8.5 wants to either see if they can verify it or point out some dumbo mistake I've made

[Ben]

In LV 8.6 I

Opened MFC.lvclass

Edit "Max Flow"

Open Readback and name change propogated

Same for  "Force Open".

So in LV 8.6 with the LV class open the names propgated fine.

Ben

PS Under the message options, please un-slect that earlier reply as a solution since it did not solve this problem and we want to make sure others don't get the impression this Q has been answered.

[JeffOverton]

Ok, did you do anything special to edit Max Flow, or just open the .ctl and change the name?

Because that certainly isn't working for me, so this might be an extension of that known cluster bug.

[Ben]

I can confirm your observations.

Bad in LV 8.5

OK in LV 8.6

Ben

Message Edited by Ben on 11-24-2008 02:54 PM