hidden front panel has undefined type

[ochensati]

I am trying to fix a very large unruly labview program.   I have a subVI that is connected to the main program by a very large unpleasant cluster.  When I change anything on the subVI, the error: "Hidden Front Panel has Undefined Type". 

The indicated cluster control definitely does not have an undefined type, so how do I handle this error?  I went back to the original cluster in the parent vi and created a control from the cluster and copied this over, and get the same error.  I am at a complete standstill from this behavior. 

Thanks for the help.

[smercurio_fc]

Are you sure you're looking at the control that LabVIEW is complaining about? Can you see the terminal on the block diagram? If you double-click on the terminal on the block diagram does it highlight the control you think it's complaining about? Have you tried to do a force recompile (hold down control key and press the run arrow)? What version of LabVIEW are you using? Can you show us at least a screenshot of what control LabVIEW is pointing to?

[ochensati]

It is labview 8.6.   It appears that the error is just a nonsense error.  If there are no errors on the vi, it goes away.

[aeastet]

I have seen this before many times. I push the run (broken Arrow) but istead of show an error the program just starts and I never have a problem again. It happens once in a while after I cahnge something. It is just annoying is all.

[Broken_Arrow]

I have the problem when the V is broken, and I fix a type def to repair the VI - when I come back from the Custom control editor, the VI is broken, but click the broken arrow and all is well.

[GRamy]

Hi

Can you show me the screenshot of the error ?

possible share your VI screenshot....i mean main vi

Thanks

[Ray.R]

I had the same error yesterday, using LV10SP1.

It was simply a hidden broken wire.  Cleaned it up, the error was gone, code ran.

Don't know why it kept complaining about an unrelated cluster control.  

Just glad I had found this thread and thought of doing a ctrl-b..  

Thanks Broken Arrow!

[JÞB]

It seams reprocuable with VI server referances linked to a type def.  update the typdef and the referances sometimes change class (since the dirty dot flag is set on vi.s with instances of the typedef the type is in limbo)  manually selecting the correct server class (or forcing a compile) resolves the " error"  The discription isn't discriptive- unless we are peeking under-the-hood at how propagation of type changes to type defs are implemented with the ability to undo after save.

[Ray.R]

There is a type-def cluster of control references...  which falls into part of what you described..

But how does that relate to the broken wire?

[JÞB]

I GUESS

---

@Ray.R wrote:

There is a type-def cluster of control references...  which falls into part of what you described..

But how does that relate to the broken wire?

---

Possibly to find what wires are broken somethings got to check types? Ctrl+B might just propagate the "Pendingness" of type change.