asbo

Having to do workarounds like this makes me wonder why a VI property isn't added to force a FP to be included. Is it just a legacy thing or is there a technical reason?

I hadn't heard that before, thanks for the clarification.

If I'm understanding correctly, you just wrap your heavy-lifting code in a case structure that uses the sentinel value as its selector. I think that would be enough for LabVIEW to know what's up.

If you're still leaning toward the iPad route, my brother has a leather case for his which wraps around and has a Bluetooth keyboard in it. Pretty neat, lets you prop the iPad up at an angle and type. No where near the responsiveness of a physical keyboard on a laptop, but still useful.

It looks that way. I checked the buffer allocations on two different string functions I think shouldn't need to re-allocate the string, but both showed allocations.

Just wire the error output into a case structure. In the "Error" case, put a "Clear Error" and pass False to your "In Use?" output. In the "No Error" case, close the port and pass out True.

I've always thought it would be handy to have a way to differentiate between an unwired terminal and a default-value terminal, not that I often come across a use case for it.

There may be an easier/cleaner way, but you could attempt to open the port; if it fails, it's in use. Make sure you close it again, though.

This isn't a symptom of iPhone versus Android, really, unless they're built-in apps and that would surprise me. I've programmed for both platforms and I think that Android is much easier to write code for. It would correlate that more people write apps for that platform which maybe don't have the polish that they should. Also, Android is at a disadvantage hardware-wise; the i* platform has very little hardware variation.

It sounds like Tamper Protection just protects Symantec SW from being altered somehow (not sure what kinds of stuff it prevents). If you're not running your LV App, does the system still hang-up? There's a lot of black magic in how LV actually does what it does in the RTE (to me, anyway), so it'd be hard to pin-point exactly what's causing a problem without knowing the implementation details of both your software and Symantec's software. Can your customer open a support issue with Symantec?

Can you post a stripped down example of the method you have so far?

There's not much to go on here. Does it appear that any of your code is executed before this happens? Add simple logging code to track how far the application gets before the crash occurs.

Even with the linked NI thread, you're going to need to explain a lot more about what you're doing or break a simpler example before people start diving into help. I understand that you're heavily invested in this problem, but even people with the know how to help aren't getting paid and have no vested interested to spend time on this. In the first ZIP, at least, I don't remember seeing much in the way of commenting.

I don't use this (yet?) but I feel like it would be better to have your Enqueue VI be polymorphic and have an instance which takes either a 1D array or cluster of strings to facilitate arguments. No precarious parsing and your dequeue always returns two strings, one case and one argument. It seems cleaner. If you need more complex parameters than a string, you could go off the deep end and have the parameter be a variant which is VTD'd by small-footprint helper VIs in specific cases. No muss, no fuss. Anyone ever tried using explicit parameterization like this?

The story behind that handle is truly uninspiring. It came to be as a smattering of keys years ago, but since I've found out it also exists as ASBO, ASBO, ASBO, and Asbo. Go figure.

What are you talking about? It's just a very well-controlled flame.

Indeed they were. I wasn't necessarily commenting on the state of the US versus other countries so much as the US being the only place I've lived long enough to comment on.

Just have the property start returning random values. Developers will realize it's unreliable and just stop using it.

I tend to following both of these practices, though occasionally I'll break the top/bottom rule if the input isn't used some ways into the VI, somewhere off the first screen of the BD. This tends to happen with CLN- or property-node-heavy code. I used to think this way, but I abandon it not long after starting LabVIEW. The front panel is for matching the conpane, the BD is to organize whatever makes the most sense. Sometimes that ends up matching the conpane, but usually only in simple VIs.

Since it doesn't like anyone's biting for you, I'll chime in. What you're saying is all Greek to me, having never touched WinCE (took me a long time to figure out what "Wince" might be ...). If you haven't tried posting there (you mentioned reading some posts), you may get more response over on the NI forums - NI support folks tend to patrol semi-regularly.

I thought Catch-22 was great, but it had a huge lull toward that end that turned me off. I've read both 1984 and Brave New World in chunks, but never end-to-end. Both are depressing in that I see them as very real futures (at least in the United States...). While not in the vein of depressing books, I thought Animal Farm was an interesting observation of societal evolution.

Does .NET have a license manager assembly that you could load beforehand and import the license at run-time? In the past, I've dealt with .manifest files which allow you to basically late-bind resources to an executable. I'm not sure if this or a similar mechanism would work in your case.

I found it more amusing to preserve it verbatim.

I vaguely recall a native implementation (non-DLL) of MySQL developed by ShaunR (I think), if that'd save you from moving to Postgre. Nope, it's SQLite.

Wow, guys, make drjdpowell feel bad, why don't you?