Jump to content

candidus

Members
  • Posts

    109
  • Joined

  • Last visited

  • Days Won

    11

Everything posted by candidus

  1. 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?
  2. 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
  3. 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
  4. 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: 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
  5. 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.
  6. I thought about a solution using "Reshape Array": Here is an example: ReshapeArray.vi
  7. 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.
  8. I missed this information several times before... Many thanks!
  9. 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...
  10. Great! I didn't think about that but it's exactly what I was looking for. Thank you very much!
  11. 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
  12. 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.
  13. You're welcome. I'm happy to hear that I could help.
  14. 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.
  15. 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.
  16. 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) 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.
  17. Very primitive but I think you will get the idea:
  18. QUOTE (stevea1973 @ May 3 2009, 04:40 AM) 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.
  19. 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?
  20. 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.
  21. Here is my example using an occurrence as mentioned above: Download File:post-15449-1240991516.vi
  22. QUOTE (Antoine Châlons @ Apr 28 2009, 03:46 PM) Very useful link. :thumbup: Thank you!
  23. QUOTE (Ton @ Apr 28 2009, 01:46 PM) Thank you very much! There are treasures buried in OpenG but only a few people know about them :thumbup:
  24. QUOTE (rolfk @ Apr 28 2009, 01:58 PM) 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!
  25. 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?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.