asbo

I did a search for forum posts ("windows message queue", I think) and noticed that the avatars next to the last posters' names did not belong to the user in question:

Sure - in Windows API programming, I'll often go through the effort of making a pretty, typedef'd cluster to pass around instead of using an array of bytes. Both work (in most cases), but the cluster is much cleaner. That what you mean? It's a pretty broad topic

I haven't seen any completed solutions, but I know that I posted a small utility that handles opening the block diagram of VIs.

No problem It's pretty simple code, but make sure you put it through its paces before deploying on x64, I only have access to an x86 install of LV.

Not that I have any particular insight, but I'm interested in what kind of interface would be implemented between the host and XPe unit. Would it essentially look like the summation of all the USB hardware it is hosting itself?

This isn't a terribly complex API call, so I doubt you'll need this, but I had a play at it. The cluster should be typedef'd, but ehhhh. If you use this and your computer explodes, I am not liable, etc etc. I've only tested it on Windows 7 x86, LV 8.6 and LV2009. A customer has had me doing a lot of API-based stuff lately, so I've developed a sick fascination with these. I had a pipe-dream of developing a ShellIcon library in LV, that might come to fruition soon. GlobalMemoryStatusEx.vi Get Win32 Error Message.vi

Well, the members page offers options to filter by group, but it seems like the way that the only admins/mods that show up are the bot-y ones. I would just report your own post and leave a description. Any moderator or admin will be able to see it then.

Make sure you're keeping your EXE next to the data subdirectory the App Builder generates for you. It will have a copy of the lvanlys DLL and this is the first place the EXE will look for the component. I don't know if it fallback to the system copy or not.

I think this response isn't as thorough as the idea probably deserves, but in short it's an interesting perspective but seems like a pretty radical change to the LV paradigm. The FP and BD are pretty comfortably categorized functionally and I don't often find myself disagreeing with the delegation of functionality. The fact that it would be such a tremendous change to business as usual doesn't bode well for it being implemented.

RE, the first: So what behavior are you expecting? I consider clusters with named elements to be a scoped namespace and a proper namespace shouldn't allow duplicate variable names (I don't know of any programming languages which allow variable overloading - loosely typed languages can be used for this in a roundabout way, though). I don't think this is an uncommon perspective on clusters. RE, the second: This strikes me as a niche case, and my reasoning against the value of adding this functionality is more or less in line with my first response. From personal experience, these VIs get used most often when human-readable files are either desirable or necessary. It seems counter-intuitive to introduce features contrary to that. Why would you want anyone to have to figure the difference between Boolean1, Boolean2, and Boolean3? In what scenarios would you not have the ability to name these elements at development time?

If I'm not mistaken, a non-unit'd value wired against a unit'd value should break the wire. I don't have LV2011 installed either, so I can't take a look at those VIs.

Actually, that's a pretty good question. If you drop one from QD, it still has the Variant Palette sub-menu on the context menu ... where it's not present.

Effectively what you have there is a Producer-Consumer architecture and that's perfectly okay (and actually a pretty popular pattern in LV apps). There are a couple other nodes that are designed specifically for communications, check out Notifiers abd Occurrences. You may be more comfortable implementing one of those for signalling across parallel loops. Because you're only looking to send triggers, user events might be overkill.

Definitely don't do the move piecemeal - all or nothing. If you want to trial it, make better versions available for brave adventurers to try on their own.

I'd like to know how long a BDCleanup takes on that Something like jcarmody's QSM might just kill it

Right, I was comparing the performance of /^[0-9a-f]$/ versus /^[0-9a-fA-F]$/. The addition of the second range of characters is where the 20% comes from. (I should have included a snippet...)

This is offtopic, sorry, but all I could think when I read OP was "How is babby formed?"

I'm not sure I see the value in implementing a strict option. Unless you're actually evaluating whether something is following MD5 spec, the case of your hex string is irrelevant to the data it contains. There's trivial overhead in exposing the option to do this, but the execution of a mixed-case regular expression suffers ~20% performance penalty in some brief benchmarks. I like Ton's idea RE: the hex string and would actually go as far to say that the string should be the only output - I've never had a use case where I need an MD5 in binary. It's always been for display or inclusion as a checksum (like VIPM does for package files and the like).

Why do you need to know the implementation details? I looked through the LabVIEW/LabWindows With TestStand manual they don't have any specific section on Express VIs, but I especially don't expect them to delve into the details of how configuration is passed around.

Someone already requested this feature for IP.B and it didn't seem to gain much traction.

I was going to tell him he was hosed, but I totally forgot about this example. Well met.

Taking a look at my Public Documents folder, it appears this is already an observed practice - but a good point nonetheless.

Ah, in that case, yes it does. I haven't messed around enough with NSVs to guide you here.

The alias file is basically a short-circuit for DNS name resolution - this won't change what IP your EXE is trying to connect to unless you're connecting by name in your code. You can pretty easily expose the IP to connect to, either in the UI, as an INI setting, in the registry, by the command line ...

Honestly, this is what makes the tool so appealing in the first place. If there's no overlays, using Windows Explorer is more advantageous to me. I hope they find some way to bring those back.