ShaunR

It's not under Front Panel. It's under Tool Bar. If you find your mind again, ask it to tell mine that I need it now.

Many moons ago I wrote a cloner for embedded devices. It basically dumped a device firmware image to an S-Record file which was then used to upload to other devices on the production line. Like Rolf said. It did enough to do the task for those devices and took a couple of hours to write the basic functionality - S-Records aren't a difficult format. It just started at an address and byte-copied chunks so only S3 was required for that (and the S0/9). I think you'll find that most people either knock up a quick utility like that or invoke the programmer utility. That's the Intel Hex format.

I think the UA_Server_run function may just write the boolean state to the running parameter (an out parm). Difficult to say with the info given but Pointer To Value for "running" might be all that's needed. The static volatile "running" variable is a red-herring in that it is an application variable that would be in LabVIEW as would the stopHandler. If the server is stopped and started by toggling the boolean, then there is a serious problem with either the DLL that exports UA_Server_run or the OP's understanding of how it works. I wouldn't be surprised if there is a UA_Server_stop which we haven't been shown.

Yeah. If you want a clean image at zoom you'll have to mask it. woopswee.vi

It is anti-aliasing because you have the zoom factor cranked up, right? Set the zoom factor to zero and get your magnifying glass out.

StrLen doesn't allocate anything. It just scans the string until it reaches \00 and returns the length minus the \00 char. It does the same as your match pattern above if you were to look at the Offset Past Match (-1). With StrLen + Moveblock, you are finding how many bytes you need to allocate to hold a *copy*, then copying from s[0] to another location (the initialise array in the VI I posted). The memory of the source string you are copying must already exist, somehow, otherwise bad things happen.

Ditto what Rolf said about corruption. Here's the PtrToStr VI with Rolfs suggestions. PtrToStr.vi

I think I may know what's going on here. char *s; /* If a string user is responsible for * allocating memory. */ The "v" in your cluster is actually a pointer to char so v in your cluster should be an array of bytes which *you* will initialise with n bytes. i.e. You have to create the pointer. The function obviously copies data into your string (byte array) which is why you have responsibility for allocating the memory, rather than the function allocating the memory and you copying the data into LabVIEW. So you are going to either something like this: or this What are you doing? The second one?

Yeah. Didn't think I'd get a definitive answer since size_t is only guaranteed to be greater than 15 bits. For MS it is UINT_MAX, which could be anything. The only way to know for certain is to test the compiled environment but even then it depends on things like if functions use 32 modular arithmetic. I don't think it can be resolved conclusively in LabVIEW but the choice is only unsigned pointer sized integer or a conditional case for target bitness. I guess you are alluding to the conditional for "most likely not to fall over in most circumstances" That's what they said about disk drives and look what happened

Is that regardless of Application bitness? Should this be a unsigned pointer sized integer or is a more complex solution required to ascertain the OS (target) bitness?

Are you sure you don't have a pointer to an array of strings?

If you are tryin g to dereference a string pointer then try this. PtrToStr.vi

From your project image you seem to have many conflicts. It's likely that you are picking up another version or VI's in a different location in your project. You need to resolve the conflicts before any troubleshooting can occur.

There's a UI User group over on the Dark Side. If you hunt through it there are a few UI's like Star Trek, Media Interfaces and iPhone simulations.