Leaderboard

Have you ever being frustrated by getting your project stuck after you running it and realized that you forgot to close one (or few) of your model style subvi(s) (which show front panel when called) ? You can not do anything on your main front panel as the model vi is in front of everything and you can not stop it either! All you can do is to kill LabVIEW and re-open the project. I believe that LabVIEW should has an option to stop anything, anywhere,anytime when you are in the development environment. This has always been an issue since I started using LabVIEW. Please add a method to the next version of LabVIEW such that developers can stop thing like this from happening.

Unless your string can have embedded NULL bytes that should not terminate it, there should be no need to pass string parameters as byte arrays. In fact when you configure a CLN parameter to be a C string pointer LabVIEW will on return explicitedly scan the string for a NULL byte (unless you configured it to be constant) and terminate it there. This is usually highly desirable for true strings. If the buffer is however binary data that can have 0 bytes, you should indeed pass it as byte array pointer to avoid having LabVIEW scan it on return for a NULL character.

No, well. not really. It depends if you are going to have nulls in your data then you could use the C String and not worry about it. However. I'm guessing that because you are looking at string length bytes (pascal style strings can be no more than 256 bytes by-the-way) that you are intending to pass arbitrary length binary data that just happen to be strings.. . There are two ways of transferring variable length data to/from a library. Memory is allocated by labview and the library populates this memory the data (library needs to know the size and the resultant data must be no more than that passed - create and pass array like the ol' for loop of bytes) Memory is allocated by the library and labview accesses this memory (Labview needs to know the size and the resultant data can be any size- moveblock ). Either way. One or the other needs to know the size of the allocated memory. The general method is case no.2 since this does not require pre-allocation, is unlikely to crash because the data is too big and only requires one call for allocation and size, You call the function and have the size as one of the returned parameters and a pointer (uintptr_t) as the other Then use Moveblock to get the data (since it will be known at that point by the size parm). You will also need a separate function to release the memory. This also happens to be the fastest CDECL calling convention is the one of choice as the STDCALL is windows specific (you are intending to port this to other platforms.....right?)

No you can't avoid having to preallocate the strings and arrays by the caller if you want to make everything like you imagine. There is no way the LabVIEW DLL can allocate C string or array pointers and return them to the caller, without limiting the caller to only use very specific deallocator functions provided by your library too, or to never link with a different C runtime library than the one you used (that doesn't just mean a specific type of compiler but even a spedific C runtime version, even down to the last version digit when using side by side (SxS) libraries, which all Visual C versions since 2005 do). This is the old problem of managed code versus unmanaged code. C is normally completely unmanaged! There exists no universally accepted convention for C that would allow to allocate memory in one place and deallocate it in another place without exactly knowing how it was allocated. This requires full control of the place where it gets allocated as well as where it gets deallocated. And if that is not both in the caller, that is seldom the case and usually also perverts the idea of libraries almost completely. The only way to not have the caller to preallocate the arrays (and strings) is to have a very strict contract (basically this is one main aspect of what managed code means) in both the caller and callee about how memory is allocated and deallocated. This happens for instance in DLLs that are specifically written to handle LabVIEW native datatypes, so LabVIEW as a caller does not have to preallocate buffers to unknown sizes and the DLL can then allocate and/or resize them as needed and pass them back to LabVIEW. In this case the contract is that any variable sized buffer is allocated and deallocated exclusively by LabVIEW memory manager functions. This works as long as you make sure there is only one LabVIEW kernel mapped into the process that does this. I'm not entirely sure how they solved that, but there must be a lot of trickery when loading a LabVIEW DLL created in one version of LabVIEW into a different version of LabVIEW to make sure buffers are allocated by the same memory manager when using native datatypes. But enforcing to use LabVIEW manager functions to your C users so you can pass LabVIEW native datatypes as parameter is not an option either, since there is no officially sanctioned way to call into the runtime system used by the LabVIEW DLL from a non LabVIEW process. Also your C programmers would likely spew poison and worse if you tell them they have to call this and this function exactly in such a way to prepare and later deallocate the buffers needed, using some obscure (to them) memory manager API. This is not even so much bad intention by NI and the LabVIEW developers but simply how programming works. The only universally safe way of calling functions with buffers is to both allocate and deallocate them in the caller. Anything else requires a very strict regime about memory manager calls to use, that can work if designed in the programming framework from scratch (C#) for instance, but C and C++ existed long before there was any programming framework that would care about such things, and many programmers have attempted to add something to C and C++ like that later, but each came up with a different interface and each of them always will remain an isolated solution not accepted by the huge majority of other C and C++ users. Basically if you want to go the path you described you will have to bite the sour apple and use C pointers for arrays and strings, and require the caller to preallocate those buffers properly.

It is possible to request to present the regular 4 hours CLA exam again for re certification if one doesn't like multiple choice exams. Remember that anyone who is going through the CLA-R had to do the 4 hours CLA first and even before that the 4 hours CLD test, which I agree neither of them should not be taken as the only indication of someones capacity, but it is a good filter. Personally, before hiring someone for a job I ask them to show me their code.

I used Shared Variables in a project about seven years ago to communicate between a Windows touch-panel and a RT controller. I thought I was having a similar issue until I realized that it took as long as 0.03 seconds for a SV to update. Are you relying on a write in the initialization to be read in the downstream loop? It could be that your code gets there before the SV actually updates. Maybe not.

Well my answer will be as insightful as your question. Open the vi source, add tab control, build new executable.

Why not. This will help you access the same object even if you branch the HAL Wire. Also it helps you locking the resource. Memory Wise, I think it could be an advantage, if the Aggregated Object Contains Huge amount of data. By replacing that with a 4byte DVR reference value, the HAL-Wire don't become so heavy. So e.g. if you branch the Hal-wire, or when you go into many SubVIs, those SubVIs has to allocate memory for this Huge amount of data. But should you ever branch a ByValue Wire? If you want to run things in parallel and accessing one object, you have to go with the Actor approach, or...just use ObjectByReference. //Mike

I hope what you are doing *is* fine. I would want to live in a world where it is fine. I tried asking our NI lawyers, without mentioning your name or pointing in LAVA's direction, whether this sort of thing is ok. You know what answer I got? It is *illegal* for our lawyers to answer that question on your behalf. We have published the EULA. It is up to you, in consultation with *your* lawyers, to decide what that EULA means and whether it applies to you, and if at some future point we feel that you are not abiding by the EULA, that's what judges are for. I was very plain... "Are you saying we cannot tell our customers what they can and cannot do with our software?" They replied, "Of course we can. That's what the EULA does. We can't put it in any other language as that would be considered a separate binding contract." Let me repeat, just so it is clear... this isn't an NI thing. This is the legal requirements of lawyers operating in the USA: they cannot give legal advice to clients they do not represent, especially if those clients are possible future opponents in court to clients they do represent. So then I asked the next logical question... can the *business* side of NI tell our customers whether what they are doing meets the EULA or not? Answer: Yes, but we would advise them not to do so because it wouldn't be binding. In other words, the EULA is binding, and if someone from NI says, "It's ok for you to do that," you might still be sued later if we decide we didn't mean it and as long as it isn't an official legal opinion, it doesn't amend the EULA. This is what is referred to as "adversarial justice", which is the style of law that we have established in the USA. Lawyers are meant to square off against each other and judges decide who wins. In the meantime, a company, indeed, an individual, should treat all other parties as legal enemies, even those that they are friends with in other domains, i.e., commerce. The more I learn about this stuff the more I am convinced we need a really different legal system for some of these modern constructs. By the way, here's a fun one... I heard about a company that has the children of workers come in after school to install software. The kids click on the EULA when doing the installation. Contracts signed with minors are non-binding, so this company feels that the software, by failing to validate the competency of the person clicking that I AGREE button, has allowed itself to be run without any of the EULA terms applying. Is this legally sound? Their lawyers think so and it hasn't been challenged in a court of law. And until you've been to court, saying something is legal or illegal is impossible. It is just what your lawyer says is likely to be legal. Yeesh. Good luck, flarn. At the end of the day, I think the only thing I can say is that as long as you're not wealthy from any revenue source, you're probably safe from lawyers. Probably. Although Rolf makes a good point about why you might not be. So if you're going to use any software you didn't write yourself, I think you have to retain a good lawyer. Unless your EULA requires binding arbitration, as some do nowadays. Yeesh.

Exactly. This is purely for fun; it would be idiotic to use this in any important VIs. Here's a tip for editing objects: copy something to the clipboard, and then select BDHP Clipboard or FPHP Clipboard on the left (for block diagram or front panel, respectively) and select the object on the right with an asterisk before its name.

That's the "She was asking for it" argument and says it all really!

Well. The adult way to go about it is to furnish NI with the exploit so they have the chance of evaluating whether they want to expend the effort in plugging it before you release it into the public domain. This would allow you to gain a moral position rather than just looking like a petulant script kiddie. Careers have been made this way and the skills are usually prized rather than punished. White hats and black hats come from the same milliners, however they are viewed and treated very differently both in the community and in the law courts.

Your curiosity will have to be satisfied with "a certain way we can configure the UI to make controls generic".

Rather than getting worked up about useless (or even dangerous) parts of LabVIEW, here's a couple of nodes from the New VI Object list that are actually useful, along with what it appears they do: Swap Vector Elements Takes a 1D array, and swaps one element with a new value in a memory-efficient way. Get Fixed-Point Components Pulls out information about the nature of a Fixed Point variable. And here's one that looks like a no-op -- though I'm happy to be corrected Transpose 1D Array

No, I can't post a screenshot. Your curiosity will have to be satisfied with "a certain way we can configure the UI to make controls generic".