"To more specific class" in executable returns an error in executable

[RagingGoblin]

Hi,

I made a vi that invokes a property on all xcontrols on the front panel. In order to get a reference to all controls I use a property node Controls[] and use the "to more specific class" function to get a reference to my specific xcontrol. This goes well within labview, but after building an executable of this, an error is returned by this function.

How can I cast this reference to my specific xcontrol?

thanks.

[Aitor Solar]

I tested the same code with an XControl of mine and it works. What's the error your exe returns?

Saludos,

Aitor

[crelf]

QUOTE(RagingGoblin @ Jan 17 2008, 04:16 AM)

I made a vi that invokes a property on all xcontrols on the front panel. In order to get a reference to all controls I use a property node Controls[] and use the "to more specific class" function to get a reference to my specific xcontrol.

I know this is of little help, but your code looks fine to me - I think that you certainly *should* be able to do what you're trying to do...

[Aitor Solar]

Now, though I don't get an error I've found this code fails to read a property when compiled. I have prepared a simple example using the Dual Mode Thermometer that ships with LV, as shown in the capture. This works as a VI, but fails in an EXE (it never returns True).

Saludos,

Aitor

[crelf]

QUOTE(Aitor Solar @ Jan 17 2008, 08:41 AM)

I have prepared a simple example using the Dual Mode Thermometer that ships with LV, as shown in the capture.

Can you please post the code so we have it here for future reference?

[Aitor Solar]

QUOTE(crelf @ Jan 17 2008, 03:40 PM)

Can you please post the code so we have it here for future reference?

Sure, but it's just the code I posted. Run the VI, the boolean goes to true. Compile it and execute, the boolean will remain false no matter the mode the XControl is (Farenheit or Celsius).

It seems a bug, I'll talk with NI about it.

Saludos,

Aitor

[RagingGoblin]

QUOTE(Aitor Solar @ Jan 17 2008, 05:12 AM)

I tested the same code with an XControl of mine and it works. What's the error your exe returns?

Saludos,

Aitor

This is the error I get:

Error 1055

To More Specific Class in invoke_all_xcontrol_indicators.vi->test_publ.vi

I use version 8.20, on the NI board I saw the same post:

http://forums.ni.com/ni/board/message?boar...hread.id=287670

In the upgrade notes from version 6.02:

The To More Specific Class function used with a control reference as the target class input no

longer returns “error 1055” in built applications.

[crelf]

QUOTE(Aitor Solar @ Jan 17 2008, 10:37 AM)

Sure, but it's just the code I posted.

I meant include the xcontrol too.

[Yuri33]

Raging Goblin, I'm the one who created the NI forum post you referenced. I never responded to the NI engineer because my code was both massive and propriatary. I continued to ask for support via private communication with the an NI engineer, but they were unable to find a satisfactory solution beyond upgrading to LV8.5, which I was unable to do.

I thought I was being clever by storing an array of generic references that I can typecast as necessary. The solution I eventually came up with is a dumbed down way to do things, but at least it works:

I created a global (not LV2, but true global) that contained strictly-defined references (i.e., they have a little orange star) to all the controls I needed to reference. At the beginning of my program, I created references to all these controls and stored them to the global. Whenever I needed a reference to a control, I then simply read from the global. When compiled, my program executed properly.

What this means, however, is that I cannot dynamically reference my controls, since I'm using references to strictly typed controls. Compiled LV seems fine typecasting to a more generic form (either by "To more generic class" or by simply collecting a bunch of strict references into a common array), but like you posted, typecasting to a more specific class produced problems in the executable.

One more thing: the global solution above worked for every control I had except Image controls. According to the NI engineer I worked with, it seems that there is NO way (at least in LV8.2) to store a strictly typed refernce to an Image Control, or even to pass it to a subVI, which to me is really strange. In the developement environment, I could typecast the control to a generic form to store and\or pass it to subVI's (where they can be recasted back to an Image control reference), but as you've seen, this doesn't work in the executable. My only recourse was to execute all property reads\writes and\or methods for Image Controls directly in the VI where Image Control was located in (in my case, the top level VI). This made for bloated and ugly sections in my top level VI, but that was what I had to live with.

[Aitor Solar]

QUOTE(crelf @ Jan 17 2008, 05:37 PM)

I meant include the xcontrol too.

That XControl is provided with LV, it's located in examples/general (look for something like Dual Thermometer).

Saludos,

Aitor

[crelf]

QUOTE(Aitor Solar @ Jan 17 2008, 03:32 PM)

That XControl is provided with LV, it's located in examples/general (look for something like Dual Thermometer).

I know that (you said it in a preivous post): I wanted you to put it here too so that everything to do with your question resides here on LAVA, so that, in future versions of LabVIEW when that xcontrol might be gone, the thread doesn't date. It's not a big deal, so don't worry about it if you don't want to.

[Aitor Solar]

QUOTE(crelf @ Jan 17 2008, 09:55 PM)

I know that (you said it in a preivous post): I wanted you to put it here too so that everything to do with your question resides here on LAVA, so that, in future versions of LabVIEW when that xcontrol might be gone, the thread doesn't date. It's not a big deal, so don't worry about it if you don't want to.

Oh, well, but that code belongs to NI, isn't it? Can we post VIs that ship with LV?

Saludos,

Aitor

[Aristos Queue]

QUOTE(Aitor Solar @ Jan 18 2008, 02:12 AM)

Oh, well, but that code belongs to NI, isn't it? Can we post VIs that ship with LV?

I don't know the answer to that question but you should ... don't you read your shrinkwrap license agreements?

[Aitor Solar]

QUOTE(Aristos Queue @ Jan 19 2008, 04:12 AM)

I don't know the answer to that question but you should ... don't you read your shrinkwrap license agreements?

No, not really, I just work with the software determined for each project, licenses are held by another person. BTW, why do you feel obliged to tell me what should I know? It sounds rude, IMHO.

Saludos,

Aitor

[Aristos Queue]

QUOTE(Aitor Solar @ Jan 19 2008, 01:44 PM)

No, not really, I just work with the software determined for each project, licenses are held by another person. BTW, why do you feel obliged to tell me what should I know? It sounds rude, IMHO.

Apologies. I should've put a on that. No one but the most lawyeristic among us reads shrinkwrap licenses, even though we all probably should so we'd know what we could and could not do with our softare. It's something I've complained about more than once on LAVA, the complexity of knowing what rights we have with VIs or any other IP generated from any piece of software.

[Aitor Solar]

QUOTE(Aristos Queue @ Jan 19 2008, 11:16 PM)

Apologies. I should've put a on that. No one but the most lawyeristic among us reads shrinkwrap licenses, even though we all probably should so we'd know what we could and could not do with our softare. It's something I've complained about more than once on LAVA, the complexity of knowing what rights we have with VIs or any other IP generated from any piece of software.

All right, then . And you are correct, licenses are complex and that's why I prefer not to get messed with them. Anyway, about the original question, I handed the code over to NI Spain to see if they find the same behavior.

Saludos,

Aitor

[Tomi Maila]

QUOTE(Aitor Solar @ Jan 20 2008, 11:57 AM)

And you are correct, licenses are complex and that's why I prefer not to get messed with them

Does this mean you are not interested in complex LabVIEW problems either?

[RagingGoblin]

Yuri33, Thanks for you answer and you suggestion. As you say an 'ugly' solution, but appearantly we have to live with this, I will adopt your strategy.

[Aitor Solar]

NI has solved the problem (again). In the "to more specific class" don't make the target class strict (so, don't use a reference to the XControl in the FP, but a class specifier constant to the XControl class). Anyway, it seems to me this is still a bug in the runtime engine, though a workaroundable one, either using non-strict references and converting variants to the correct value type, or using a "type cast" to the strict reference instead a "to more specific".

QUOTE(Tomi Maila @ Jan 21 2008, 12:03 AM)

Does this mean you are not interested in complex LabVIEW problems either?

Absolutely. That's why I reduce all LV problems to little easy chunks .

QUOTE(Yuri33 @ Jan 17 2008, 05:49 PM)

One more thing: the global solution above worked for every control I had except Image controls. According to the NI engineer I worked with, it seems that there is NO way (at least in LV8.2) to store a strictly typed refernce to an Image Control, or even to pass it to a subVI, which to me is really strange.

Well, in LV8.5 it works fine, just like other control types .

Saludos,

Aitor

[Yuri33]

QUOTE(Aitor Solar @ Jan 21 2008, 05:55 AM)

or using a "type cast" to the strict reference instead a "to more specific".

Is this confirmed to work? You can simply typecast a generic control reference to a strictly typed reference? Will this work at run-time (in LV8.2)?. I would love to change my application back to the way I originally had it (and slay the last global!), but I don't want to put the time in if I'm going to run into the error again at run-time.

QUOTE(Aitor Solar @ Jan 21 2008, 05:55 AM)

Well, in LV8.5 it works fine, just like other control types

.

Yes, the NI engineer kept trying to get me to upgrade. I'm using a university license for LV, and they're slooooooow to offer the lastest version

[Aitor Solar]

QUOTE(Yuri33 @ Jan 28 2008, 11:28 PM)

Is this confirmed to work? You can simply typecast a generic control reference to a strictly typed reference? Will this work at run-time (in LV8.2)?. I would love to change my application back to the way I originally had it (and slay the last global!), but I don't want to put the time in if I'm going to run into the error again at run-time.

Yes, I have tested it in LV8.2 both in the development environment (both methods work) and in a compiled exe (only the typecast method works). But anyway, don't trust my word, better test it with a simple example that includes your specific XControl and compile it.

Saludos,

Aitor

[Rolf Kalbermatter]

QUOTE(Yuri33 @ Jan 28 2008, 05:28 PM)

Is this confirmed to work? You can simply typecast a generic control reference to a strictly typed reference? Will this work at run-time (in LV8.2)?. I would love to change my application back to the way I originally had it (and slay the last global!), but I don't want to put the time in if I'm going to run into the error again at run-time.

It works in LabVIEW up to 8.2.1 but fails in LabVIEW 8.5. The typecast function will refuse a refnum connected to it with a broken wire. We found this in our LuaVIEW Toolkit package and had to develop a workaround for it. I sort of understand the idea behind, since a refnum is in fact something like a pointer to an object and messing with pointers can be a VERY bad thing.

There is a chance that that new behaviour in LabVIEW 8.5 is in preparation of something that might change the refnum entirely and that might make the workaround we developed for LuaVIEW in LabVIEW 8.5 invalid again in a future LabVIEW version.

Rolf Kalbermatter

[Aitor Solar]

QUOTE(rolfk @ Jan 29 2008, 07:21 PM)

It works in LabVIEW up to 8.2.1 but fails in LabVIEW 8.5. The typecast function will refuse a refnum connected to it with a broken wire.

I don't think so. In LV8.5 the type cast won't accept a strict VI refnum as the type definition, true, but we are talking about control references and those work well, also in 8.5.

Saludos,

Aitor

[Rolf Kalbermatter]

QUOTE(Aitor Solar @ Feb 1 2008, 02:34 AM)

I don't think so. In LV8.5 the type cast won't accept a strict VI refnum as the type definition, true, but we are talking about control references and those work well, also in 8.5.

Well, I see. It still might be a problem in the future, or the refusal to typecast to a strict typedefed VI refnum is maybe a bug?? Na, I don't think so.

Rolf Kalbermatter

[Yuri33]

If we're talking about control references, then strict typecasting is very necessary. I mean, the whole point of this is to essentially recreate a local reference to a control object, but on that isn't restricted to the VI the object is located in, right?

On a side note, I'm sure most of you have built large applications with plenty of UI that you offload into subVIs. How do you pass around global references of your top-level VI objects to these subVIs? I started out with a array of generic references, but I ran into the typecasting problem discussed above. So I settled on a true global.

I suppose you could make a functional global, but it's a real pain to add\remove strictly-typed references. Plus, I'm not looking to "protect" my global from race conditions--I know I will only write to them once at the outset, and then only read from them later on. Since a functional global blocks other calls until the current one finishes, that represents an inefficiency. I want to be able to have multiple parallel reads.