GOOP: Failure to Auto-update Inspector on change in data control

[Apache]

A change in the data members of an object did not result in an automatic update of data in the Object Inspector. The Object inspector hence cannot be compiled. One of the two errors it reports is that there is not enough memory to compile the inspector. The other is that there is a problem with this VI but it does not have a block diagram.

The object, however, seems to work okay. Only I cannot watch it using the inspector.

The inspector for a new object with the same data members does not have this problem.

Any ideas?

[Mattias_Ericsson]

Hi,

If I understand your problem correctly, you have modify the class objectdata type def control. Did you apply the changes in the menu of the type def ("File->Apply Changes")? else the changes will not be updated until you restart your application. If that do not solve the problem and you still have problems with the inspector (which is just a VI), I suggest that you open the inspector just as a regular VI (not from the Wizard by pressing the "Inspector" button) and edit it. It is in the class LLB. The code is open, so there should not be any problem replacing the object data and reestablish the link.

Later you write "The inspector for a new object with the same data members does not have this problem." I believe that you mean "The inspector for a n
ew CLASS with the same data members does not have this problem." All objects instanciated from a class uses the same inspector. All VIs are class VIs. An object is basically only a "memory allocation" and do not have their own VIs.

As you write, a new class will not have these problems and not will there be any problems if the "Apply changes" is made after a change in the object data type def.

The memory problem you mension, are you sure you closes all objects?, else there will be a memory leak and it will keep growing (more and more objects are created) each time you run until you restart LabVIEW or run out of virtual memory. This might be the cause of the memory problem, the solution is to restart LabVIEW.

Best regards,
Mattias Ericsson
Endevo Sweden
(member of the GOOP developer team)

Have you seen the new GOOP Wizard 2.0 at www.endevo.se

[Apache]

Mattias,

Actually, the inspector, at least what I have (version 1.0) does not have a diagram. So it is not possible to manually make changes. (One of the 2 errors is: "There is a problem with a subVI but this VI has no block diagram.")

The problem persists across restarts of the application. Apply changes did not work.

Yes, you are right, it was a different class that worked, and not a different object, as different objects would use the same inspector. I tried an identical new class because one of the errors suggests that there is a lack of memory causing the issue: "There was not enoguh memory to compile this VI". Details:"You need to make more memory available for LabVIEW to generate the code for this VI".

No, memory leak does not seem to be c
ause of the issue. All objects are being destroyed. Also, the problem arises even if the only thing I open (after a restart) is the inspector (I have tried opening it both via the GOOP wizard and directly). The machine has 256Megs of RAM.

Best regards,

Pranjal

[Mattias_Ericsson]

Hi again,

Okey, that explains why it can not recompile. You can not recompile without the source code (the diagram). Somehow you (or someone else) seem to saved that VI without the diagram, mayby the hole class does not have the diagrams (have been saved without the diagrams), but then the class would not run at all because it can not recompile the other class VIs that were affected. But it sound that these VIs are correct.

The inspector should have a diagram. However it seems that you can generate a new class that has a working inspector that could be recompiled (else there is something wrong with the template class that all classes are generated from, the _classtpt.llb file in the same folder as the Wizard is installed. I atta
ch a correct _classtpt.llb that you can use).

To solve your specific problem, let's do a little trick.

1) Close all LabVIEW code and restart LabVIEW to make sure no VI is in memory.
2) Create a new class with the exact same name as the one with the damaged inspector.
3) Open the newly created inspector as a regular VI.
4) Make a "Save as..." on the inspector into the "orginal" class LLB to replace the "old" inspector.
5) Close the inspector
6) Delete the newly created class.
7) Open the inspector again in the "old" class.
😎 It will now search for some VIs but finding them in the class
9) Resave the inspector and it should work.

Hope this help!

Regards,
Mattias

[Apache]

Yes, that worked.
Thanks much.
Pranjal