Get .ctl Reference of a **NEW** Class (not yet saved)

[jgcode]

Howdy!

I use this method of getting the .ctl reference of a class (posted by some of my smashing friends here at LAVA ).

However, when the class is not saved I get error 1004.

So my question is... ...Is there any way I can get a valid reference when the Class is not yet saved?

Cheers

-JG

[Francois Normandin]

Howdy!

I use this method of getting the .ctl reference of a class (posted by some of my smashing friends here at LAVA ).

However, when the class is not saved I get error 1004.

So my question is... ...Is there any way I can get a valid reference when the Class is not yet saved?

Cheers

-JG

Hi Jon,

You can get it through the class' library children. The type is "Class Private Data" and it's the only child of this type in the library. The other method relies on the path being known, which doesn't exist yet if not saved, or at least, it exists only in a temporary location.

As a bonus, you can get it from LVClass API...

But here's how to do it without:

[jgcode]

Hi Jon,

You can get it through the class' library children. The type is "Class Private Data" and it's the only child of this type in the library. The other method relies on the path being known, which doesn't exist yet if not saved, or at least, it exists only in a temporary location.

As a bonus, you can get it from LVClass API...

But here's how to do it without:

You knowledge of the force class is strong

Although I always want to know how to do it myself.... I think its time to get more intimate with your API (I have downloaded and looked at it before, just so you know).

Do you recommend this over the other method? I remember AQ mentioning about the class being in memory before getting a reference to the .ctl etc...

Kudos!

[Francois Normandin]

You knowledge of the force class is strong

Although I always want to know how to do it myself.... I think its time to get more intimate with your API (I have downloaded and looked at it before, just so you know).

Do you recommend this over the other method? I remember AQ mentioning about the class being in memory before getting a reference to the .ctl etc...

Kudos!

I think AQ doesn't like us to thinker with the private controls, unless we do it with great care and knowledge that we can screw up big time.

I'd recommend the reference method posted above over the named "Open Reference" method, simply because it is universal. The class resides in memory when you create it, whether or not it's saved, so the reference will always work.

As for the API, it's missing some bits and pieces, and I'm putting together a better version as we speak. I've had some issues (minor) with building a temporary package, so I have nothing at the moment... I shall try to have it for NI Week. I did think about asking you for collaboration in integrating some methods for icon management, since you seem to have worked a great deal on this. I guess I'll PM you when I'm ready to explore that.... if you don't mind of course!

[Aristos Queue]

For any class that is in memory (and a never saved class is obviously in memory), just do "name of class" + ":" + "name of class but replace .lvclass with .ctl" and wire the resulting string to the Open VI Reference primitive. Voila.

[Francois Normandin]

For any class that is in memory (and a never saved class is obviously in memory), just do "name of class" + ":" + "name of class but replace .lvclass with .ctl" and wire the resulting string to the Open VI Reference primitive. Voila.

It seems I was shooting a *insert small animal name here* with a bazooka... So Jon's error 1004 (The VI is not in memory) was not related to this?

[jgcode]

As for the API, it's missing some bits and pieces, and I'm putting together a better version as we speak. I've had some issues (minor) with building a temporary package, so I have nothing at the moment... I shall try to have it for NI Week. I did think about asking you for collaboration in integrating some methods for icon management, since you seem to have worked a great deal on this. I guess I'll PM you when I'm ready to explore that.... if you don't mind of course!

Collaboration sounds like a smashing idea!

I have been playing around with Layers using the Icon Editor API, so its all 2009.

But there may be some stuff there that would be of benefit.

We should definitely have a chat offline.

For any class that is in memory (and a never saved class is obviously in memory), just do "name of class" + ":" + "name of class but replace .lvclass with .ctl" and wire the resulting string to the Open VI Reference primitive. Voila.

Getting to the class by the Name property works, whereas the Path property returns a blank when the class is not saved and the Open VI Reference for the Control returns the error 1004

The name mashing is still the same as it is still similar to the previous thread.

I guess it only matters if you are reading the class off disk and not in memory, then it would be saved anyway so use the Path.

It all seems so Basic I Core 1 'ish now....

vs

@ Francois

Not at all...more than one way to skin cats.

I learnt something and that is never a bad thing.

[Francois Normandin]

@ Francois

Not at all...more than one way to skin cats.

I learnt something and that is never a bad thing.

There's just one way to skin a cat... BAD! (Did I mention I love cats?)

We'll continue this offline... probably on a rainy day!

BTW, Thanks AQ.

[jgcode]

We'll continue this offline... probably on a rainy day!

What does that mean?

Does it rain often in Montreal?

(Home of the great GSP - you didn't go to UFC 113 @ the Bell Centre did you?)

[Francois Normandin]

What does that mean?

Does it rain often in Montreal?

Not particularly, but I don't usually code much when I see this:

UFC... that's lame when Montreal Canadiens are going for the Stanley Cup!

Seriously, we only hear about hockey these days...

[jgcode]

Not particularly, but I don't usually code much when I see this:

UFC... that's lame when Montreal Canadiens are going for the Stanley Cup!

Seriously, we only hear about hockey these days...

Whats hockey?

[Aristos Queue]

Getting to the class by the Name property works, whereas the Path property returns a blank when the class is not saved and the Open VI Reference for the Control returns the error 1004

The name mashing is still the same as it is still similar to the previous thread.

I guess it only matters if you are reading the class off disk and not in memory, then it would be saved anyway so use the Path.

Just noticed this... actually, you would *always* use the Name and never the Path. Why? Because the class name will include its fully qualified name. If the class happens to be a member of a library, it's qualified name is X.lvlib:Y.lvclass, and you need that full qualification when you build X.lvlib:Y.lvclass:Y.ctl or else Open VI Reference by name won't work (or will give you a completely different CTL if there happens to be a plain Y.lvclass in memory at the same time).

[jgcode]

Just noticed this... actually, you would *always* use the Name and never the Path. Why? Because the class name will include its fully qualified name. If the class happens to be a member of a library, it's qualified name is X.lvlib:Y.lvclass, and you need that full qualification when you build X.lvlib:Y.lvclass:Y.ctl or else Open VI Reference by name won't work (or will give you a completely different CTL if there happens to be a plain Y.lvclass in memory at the same time).

[/left]

Yes, that is correct, as I fixed this bug in my last release of my LVOOP Theme Creator:

Version History (Changelist):

2.6-1 2010 06 28

- Fixed (): Classes as Sub-Libraries caused error as Namespace was incorrect

This one threw me for a bit as I still got the 1004 error, until I released what was going on wrt Sub-Libraries.

I use the from name always now so ended up deleting the from path method.

I was meant to post the code to this thread, in case anyone else wanted to do the same thing.

But hadn't got around to it!

Thanks for the reminder

Attached is the code I used to get the fully qualified name:

Edit: the VI Server input/output says "Class" (as in LabVIEW Class Library class) but that is just artifact from refactoring, I ended up using the more general LabVIEW Project Library VI Server class.

[Francois Normandin]

Attached is the code I used to get the fully qualified name:

I think perhaps you could use the "Qualified Name" property for the library. It seems to do exactly what you need.

[jgcode]

I think perhaps you could use the "Qualified Name" property for the library. It seems to do exactly what you need.

Damn - are you serious!

I will have to check it out...

Seems NI have done the heavy lifting....(thanks Francois!!)

Ok I take back my previous post.. this is the code I (should) have used

[Francois Normandin]

Ok I take back my previous post.. this is the code I (should) have used

I guess there are some things that "ctrl-U" can't do (yet).

[jgcode]

I guess there are some things that "ctrl-U" can't do (yet).

Maybe we could override its behavior using Dynamic Dispatching?