candidus

Is there any way to obtain this from Object in?

Unfortunately I didn't find a way to obtain that information. I provided the appropriate cluster types manually. Just a thought: Can we open a reference to the class private data control and get it from there?

Hi there,

I recently wished the OpenG "Get Cluster Element by Name" would work on OO wires...

I looked a bit deeper into this, found out that OO wires unsurprisingly aren't mere clusters but that their flattened form is documented in the LV wiki.

So I began to write a VI that parses the flattened OO data and returns the contained data clusters. Here is it:

Admittedly, I felt a little bit dirty when writing this code :-)

Looking for another solution I stumbled upon the LV XML primitives. As mentioned before, these can be used to do much the same, with some limitations. I was only interested in readonly access of basic data types, so it worked for me:

I never used these methods in production code, however.

candidus

I was looking for a way to convert a path to an URI. There seems to be nothing like that in LV so I read RFC 3986 and wrote something myself. This is my current version. It's far too simple to implement the complete syntax of a path URI found in the RFC but it seems to work so far. Has anyone ideas to improve it or a better solution?

path2URI.vi

Unfortunately I don't have a recent LabVIEW for Linux so I can't tell you whether this works,

but here are some general hints:

- have anyone tried porting windows fonts to a red hat based linux system? if so, is it possible to do this without being root, but enforce the necessary setup trough environment variables when calling labview

(the reason i ask the latter is because if i don't have root access to all the client machines)

Yes, it's possible. You can create a font directory in your home, copy your fonts there and update your font cache via "fc-cache" utility.

You can find instructions on many places in the web, for example:

http://kbase.redhat..../docs/DOC-17068

http://en.kioskea.ne...ts-under-ubuntu

The latter is for Ubuntu but should work on RedHat, it uses the same font system.

Useful information, especially links you can find in the Ubuntu Wiki (omit the installation section)

https://wiki.ubuntu.com/Fonts

Not that I'm not using Ubuntu, my system is Debian

I had exactly the same problem...

I wanted to send an event to a group of XControls.

I also had the idea tried to send a Value(sgnl) to my XControls to wake them up,

but these events were also forwarded to my toplevel event handler: It was flooded with events and caused the frontpanel to freeze...

So I ended up in not using custom events for this task. There are many things you can do with a control when

you have its control refnum without the need of sending events. For my XControl I had just to store the refnum

to the main control on the Facade FP and use it later for setting properties. Perhaps you can try a similar trick.

I thought about a solution using "Reshape Array":

Here is an example:

ReshapeArray.vi

I don't think that you need a pascal String.

Since you're working with an ActiveX object all data types must be automation compatible, however, pascal string aren't.

The only string type type allowed for use with ActiveX is BSTR. LabVIEW converts string arguments automatically to that type. If your method really would require a pascal string you couldn't even select it (LabVIEW disables methods that aren't automation compatible in the dropdown list).

It seems there must be another problem. Your error message usually means that the object isn't registered properly

(Sometimes manual registering seemed to work but in fact it didn't). Perhaps some requirements of your component are missing. Verify that your ActiveX object is registered properly and creatable, e.g. with Microsoft's OleView utility.

I missed this information several times before...

Many thanks!

If you still want to test the variant type before trying the variant casting, the 6th byte in the typedesc will tell you the refnum type (value 7 is for ActiveX Automation references). Though I do agree the other way is probably faster.

Saludos,

Aitor

Thank you!

I already noticed that this byte must have something to do with the Refnum type

but I was unsure. Is there any documentation about that? The LV documentation tells something about TDs of plain types but not much about Refnum TDs...

Is there some reason you can't use an Automation reference and Variant To Data?

ActiveXVariantToAutomationRefnum.vi

Great!

I didn't think about that but it's exactly what I was looking for.

Thank you very much!

Hi there,

I looked for a way to get the IID from an ActiveX Refnum.

So I looked at the TypeDescriptor and fortunately

it contains not only the IID but also the CLSID and TypeLibrary

of the underlying interface.

But I'm still looking for a way to Check whether my Input Variant

contains an ActiveX Refnum. I can check for Refnum,

but it must be an _ActiveX_ Refnum, else my VI has to return an error.

Currently I'm checking the length of the TD but I don't think that's

an error-proof solution.

Has anyone a better idea?

GUIDsFromAxRefnum.vi

Without looking on your code (I don't have LV8.2),

here's how you can create a graph typedef for a specific type:

Add a graph to your frontpanel. Feed your graph with an initial value

(empty data with the correct type) so the graph

set its data representation to the type of that value.

Right-click your graph, select Advanced->Customize.

Save the graph typedef.

Now it should only accept values of the type you specified.

You're welcome.

I'm happy to hear that I could help.

Hi,

the error message contains useful information about the problem:

---

LabVIEW: One or more untitled subVIs exist. This file cannot be saved until all dependent files have been named.

Method Name: Save:Instrument

---

When you instantiate your VIT it instantiates the templates it owns. You can't save your template instance before

you save its callees. Rewiring of the "Build Array" primitive puts things in right order:

First the callee, last the calling VIT instance.

Hallo,

you could try to set the parameters for a particular waveform before you plot it

instead of setting properties of the waveform graph.

Unfortunately I don't have LV here at the moment so I can't verify whether this works.

As jdunham said, you should not use a typecast but the primitive "To More Specific Class".

As I remember it isn't a good idea to use a typecast on an array, better use a For loop

and cast the elements one by one.

Try the following (error handling omitted):

QUOTE (pete_dunham @ May 7 2009, 06:44 AM)

So I infer from this code that the control reference is a static reference that is not dynamically linked to the control? Is this correct?

This seems like a limitation from passing type def. control references through subVIs...as the Control Ref is not dynamically updated (the subVI sink is looking for a different source if type def updated).

I looked a bit further into this: It seems that the problem isn't the reference (it gets updated) but the SubVI's control terminal for it.

If you create the SubVI its reference isn't linked to your cluster typedef by default so it doesn't get updated.

You have to link it to your strict typedef by yourself.

Very primitive but I think you will get the idea:

QUOTE (stevea1973 @ May 3 2009, 04:40 AM)

Just declare the entry in the node as a string and Labview will pass a ptr to a string (char * or wchar* depending on your environment I guess). All pointers are just pointers, a char* is the same as a int* etc. It's just in the dll it will treat it differently.

That isn't the full truth: Pointers are basically addresses but they differ in an important detail, the data type they point to.

char* points to char, int* to int and so on. You can't do much with a void* unless you know to what type it points:

The data type determines the layout and size of the referenced memory.

In C void pointers are used to bypass the type checking of the compiler. Your DLL internally "knows" what type it expects

and treats your pointer that way. If you want to pass a C string you first have to know what kind of string it expects:

plain ASCII which always is char*, or Unicode which is unsigned short* on win32 platforms.

If it expects char* you're lucky but if it expects Unicode you have to do further conversion before you can pass the string.

I just looked in LV6.1 and it seems the property is available:

Wire a property node to a VISA session, there's a property "Modem Line Settings -> RTS State".

Is that the one you need?

In LV7.1 you can open a VI reference to a VI that resides in a DLL or EXE.

Wire its path to the "Open VI Reference" primitive,

the parent "folder" of the VI is the DLL or EXE.

But I think things get complicated if you want to use DLLs/EXEs

built with different LabVIEW versions.

Here is my example using an occurrence as mentioned above:

Download File:post-15449-1240991516.vi

QUOTE (Antoine Châlons @ Apr 28 2009, 03:46 PM)

you might want to take a look at the http://thinkinging.com/category/openg/i-couldnt-live-without/' rel='nofollow' target="_blank">"I couldn't live without" series by Jim Kring

Very useful link. :thumbup:

Thank you!

QUOTE (Ton @ Apr 28 2009, 01:46 PM)

OpenG has a generic solution based on ocurrences as well:

is the name of the code, here is the underlying snippet:

Ton

Thank you very much!

There are treasures buried in OpenG but only a few people know about them :thumbup:

QUOTE (rolfk @ Apr 28 2009, 01:58 PM)

I think first of all that this is not even doing what you think it does or want it to do. The value

of an object refnum is the refnum itself (a 32 bit identifier that identifies the object in the current

LabVIEw context), not the data the object contains so what you try to do is assigning the refnum

to itself really.

I know that I try to assign a RefNum to itself,

I broke my problem down to this simple piece of code.

My real program tries to assign a RefNum of another control to a RefNum

as in my initial example. The only reason why I spent some more time on it

was that I wondered whether this could be some kind of unexpected behaviour in LV8.0,

because it didn't happen in previous versions of LabVIEW and, as

I verified on a PC of a colleague, it seems to be fixed in LV8.5.

Thank you very much for your explanation about variants!

Unfortunately this topic hasn't come to an end...

I still think there's something wrong with XYGraphs RefNums in LV8.0 .

I thought the following was supposed not to return an error:

But it does and it's error 91 again:

The data type of the variant is not compatible with the data type wired to the type input.

But it can be fixed: Just change the type of the RefNum from XYGraph to Waveformgraph

(the type it had in LV7.1...). No broken wire, no error, everything is fine.

It seems there is no way in LV8.0 to wrap a XYGraph RefNum in a variant

and flatten/unflatten it via type descriptor and data string.

Maybe this problem is a candidate for the LV8.0 buglist... :question:

Any ideas?