Ton Plomp

I had this for VIPM (but only for VIPM). Ton

Has anyone been working on an Oauth library for LabVIEW, I browsed the specs and how-to and it doesn't seem that complicated. Oauth is becoming more important now that Twitter is limiting (or shutting down?) the basic authentication for API calls. So I was thinking about this, but couldn't find anything on Oauth and LabVIEW. Any experiences. Ton

A little mathematics will help you on this, you can get the total number of visible rows (12), and you know your current row number (say 55), the you should programatically (how do you spell that?) set the top.row to 49. Ton

I found the code for this experiment again: SubPanels.zip Ton

Could you describe that a little bit broader? I don't think you can select a specific VI as a friend. I did not say my system was perfect, when (yes, when not if ) NI decides make friends addressable by name, I would opt for a system with wildcards, so I could deploy a system of add-ons. I would not say that xApi is deployd against xAPI, it is build on the API. One of the benefits of a modular reuse library is that you can declare dependencies and be assured that the base library is always installed. I will explain a little broader what my goal is. I built a public API (only lvlibs, no classes) that is a nice wrapper around a command line tool, I would like to make this libary public and share it with the community, anyone could build upon this library it's own tools. I have an advanced GUI in mind that uses this wrapper and would like to make some money out of this tool, and being the developer of the public API I have some deeper knowledge about hidden VIs, so I would like to give me the power to use these VIs, off-course I could export the VIs to the client tool, but IMHO is any doubling of code a NoNo. I have run into a strange side effect of friends with paths that's not so nice: -API.lvlib has declared xAPIt.lvlib and xAPI.lvlib as friends, xAPIt.lvlib is the name of my lvlib during development (t stands for temporary), xAPIt.lvlib is located in the development path, and xAPI.lvlib is located in user.lib -Now I try to build xAPI.lvlib from source xAPIt.lvlib, during the build fase I get an error from the LabVIEW compiler, stating that a library of that name is allready in memory. Which means that declaring a friend will cause LabVIEW to load it in memory... (xAPIt.lvlib called API.lvlib which refers to xAPI.lvlib). That sounds really bad and support (IMO) that friends should not have paths. I haven't reallys stepped into LVClasses, so rethinking what I said sounds silly indeed. Sorry. Ton

If I go this route I just remove the legend and create a 2D table with the correct info. Aligning something with the graph-legend is something I gave up on a long time ago. Ton

The title sounds philosophical, and the question is kinda philosophical... When you declare a library as a friend you need to provide a path to that library. I was expecting this path was only used to get the name of the library, however the LVLIB file (and I assume LVCLASS as well) stores the path and the name. I thougth this was a bit strange. Here's why I would like to refer to friends by name and not by path: I am writing an API, and an extended API (an add-on module), for convenience I would like to open up some functions that are private to API to the add-on. So I declare these functions as 'Community scope' and declare my add-on module as a friend. Everything works fine... In development. Now I make a build of my API which installs the API into user.lib (hey and maybe sets a password on the library). Then I start developing on my add-on module, which is broken since it cannot get to the private methods of the API, what happens is that LabVIEW is issuing a Cross-link warning dialog. Stating that it expects the add-on module on a different relative path to the API then it actually is. If I resolve this the API lvlib file will be changed. What if I update my API and replace it with a new version, then I have to re-connect (and alter) the API again. (I am not even talking about moving the add-on into user.lib) This wouldn't have happened when I was allowed to define friends by name (here comes a very weak analogy to real life: 'I don't care about the cell-phone number of my friends, just about there names'). I can understand how changing the linking to 'by name' may compromise the validity of classes (a friend might alter data), however a friend of a lvlib cannot alter data (I rule out a functional global inside a lvlib, that wouldn't make sense and should be class) of that library. Any thoughts/comments? Ton

Hi John, officially you should post it at OpenG.org, in the builder feature request forum. However LAVA works as well. I have been working on and off on builder, but it's a very complex program, if you want to help write code please join us! If you want to help, PM me and Jim Kring in conversation. That way we can discuss the current state and roadmap. Ton

I'm going to start a Real Time (Crio) project and it's been a while since I've been there. Last time was 5 years ago. It's an old controller and I am wondering if a how a State Machine will perform on that platform? Or any other recommandations? Ton

And maybe the most impressing one, it could crash the VI and LabVIEW and that might cause a VI-file corruption.... I know NI is working hard to prevent those things to happen, but once in a while (once a year) I see this happening to a colleague who refuses to use an event structure... Just make you don't just hide the toolbar, also disable the abort button (other wise ctrl-. will still work). Ton

Here's a little startup: StructToVariant.vi This VI will try to read a Typedef and return it's contents as a cluster with the right elements. Together with the Variant to Control (with which I would like to integrate this) you can convert a typedef-string into a (typedef) control file). I have tested the converter with the following typedef string: typedef struct { uint32 header_sz; uint32 width; uint32 height; uint16 nplanes; uint16 bitspp; uint32 compress_type; uint32 bmp_bytesz; uint32 hres; uint32 vres; uint32 ncolors; char nimpcolors;} bmp_dib_v3_header_t; and the following Enum struct: typedef enum { BI_RGB = 0, BI_RLE8 =3, BI_RLE4, BI_BITFIELDS, BI_JPEG, BI_PNG,} bmp_compression_method_t; It supports sparse Enum's for instance. It however does not support nested structs (reference to another), that might be something to add. If you make any changes I would like to see them here. As said earlier, have you looked at the Variant To Control tool-VI? Ton

I added these two to a new WIKI page called 'Application Builder', please expand this page with your knowledge on the Application Builder. Ton

Look at these KB articles: LVMerge and LVCompare. One thing to note that these tools are part of the Professional LabVIEW Suite. If you have an integrated SCC you can use the Compare function directly from within LabVIEW. Ton

Here's a snippet what Crossrulz and Scott meant: Ton

Yes there is such a VI. That VI is provided by NI. It's located at '\vi.lib\Utility\libraryn.llb\Is Name Multiplatform.vi' in LabVIEW 8.6 and up. For older version look in 'project\llbedit.llb\Is Name Multiplatform.vi' Ton

Hi sydney, if you want to get leverage on this I would advise the following: -Post here some code showing all the issues you have to go through to get a nice UI like this. -Post an Idea to the NI Idea Exchange. -Post here a link to your Idea, to get additional support (kudos) for your idea. Ton

Long shot, what happens if you make bar and baz a 2-d array? It might be that the orientation is off. Ton

Well, if you are going for multiple windows, you should set the VI to be reeentrant (don't share clones) and set the windows properties to what I suggested earlier. That should work as well. Ton

HTTP(s) client VIs. Ton

Daklu is right, you don't need reentrancy. You don't need VI server either: Just set the sub-vi to open the FP when called and don't set it to auto-close. Ton

You know that mythical thing called SCC? Yes that looks really good! Ton

I'm not sure about the calling convention, but you don't need a linux specific case. Look at the NI DAQmx VIs where they are linked to daqmx.* On each platform LabVIEW selects which file to load. Ton

Give me one good reason why the world needs more than 16 colors? [/Colour challenged] At least the queen Beatrix of the Netherlands agrees with you. (she made the Netherlands buy Victory Boogie Woogie) Ton

Make sure the .so file is in the same path as the .dll (so only the extension differ), and relink your calls to mydll.*, this should do the trick for Linux as well. Note that Linus is case-sensitive. Ton