ShaunR

We already have the UTF8 primitives that cater for 99% of cases The real problems are indicators and controls (I'm looking at you, file control). I would be happy if we could display and use UTF8 in controls and indicators. I don't really care about other encodings as I could always convert them to UTF8 for the edge cases. Also. Wouldn't need a special wire

I find it mildly amusing that a non-native English speaker knows more about my language than I do. Maybe if I had gone to Grammar School and learnt Greek and Latin, I would be more equipped to argue. However. I got an F in French so it probably wouldn't have gone well

If it's just the time you are working in LabVIEW-that is doable without writing something for windows. You could just monitor open LabvIEW windows and or projects (count them if you want). You can make it easier by namespacing VI's (e.g. myproject_someFunction) which, to be honest, I generally do as a matter of course. At a bare minimum and If you are working in projects, all you need is to monitor projects in memory and timestamp when they appear and disappear. Not folder activity-more of a project activity.

Nice. I guess there is something very LabVIEWy now!

This a blast from the past. SAE J1939 is an old Japanese protocol-the precursor to OBD. It has the same connector as OBD but slightly different pinout. If you look for software that supports early 90's Japanese car diagnostics, there used to be a few examples around. It's a bit hit-and-miss since, at the time, everyone was doing their own thing. If IIRC the early Mistsubishi's used it (FTO, GT, Galant) so a searching for J1939 with those names might reveal something. I very much doubt you'll find anything LabVIEWy so you will probably have to write a protocol driver.

Shameless plug but feedback would be great since there's a lot that's changed. A few more eyes on it would help immensely before going live. The Encryption Compendium for LabVIEW (ECL) has had a major update. It's completed and a couple of weeks away from release as the documentation is in progress so there may be a few errors on that front. It's a commercial package so the gibs free crowd will, I hope, be disappointed. So what's new? IPv6 support (Thanks Rolf for your help with that). I've been wanting this for sooooo long but it required moving away from the NI primitives and nasty text programming. I bit the bullet and now have it, although a lot less hair SFTP Since NI released their poultry offering I thought I'd productionise the SFTP I had in my back pocket for quite a while and offer something actually useful. It comes with a full client example and supports recursive uploads, downloads and deletions (be careful with that last one). It also uses events for progress and status feedback in a similar fashion to the Websockets below. The event topology will be come a common feature of protocols in future additions. Websockets The ECL is a better home than a separate product since it was very difficult to distribute when trying to support TLS. Reworked from the ground, up it sits nicely in ECL and is the start of more encrypted protocol support in the future. Oh yes. Almost forgot. The ability to use Windows Certificate Store because ... why not? (and I wish I had thought of it ) If anyone would like to play before its release proper in a couple of weeks time, I can give you a trial copy (valid for 30 days). PM me and I'll send you a link.

No idea (but highly unlikely). I've never used LabVIEW NXG and it's now defunct...so never will. Speaking of which. Does that mean we no longer have to call the proper LabVIEW "LabVIEW Classic"?

Not natively in LabVIEW. You have to use the IShellwindows interface in windows 10.

You didn't look very hard; did you! We've just been discussing the callback functions and posted examples of using them. The answer to your question though is no. you cannot use them in the way you are thinking.

In the Window menu on the LabVIEW toolbar there is an "All Windows" [last] choice (CTRL+SHIFT+W) that pops up a dialogue which you can sort. There is also a VI hierarchy and Class hierarchy graphical representation of VI's that are in memory that are accessible from the "View" menu in the toolbar. That may be easier for you if you are familiar with the hierarchies and the project is not too large (also highlights the importance of VI icons).

Nope. All the nodes are calls to the LabVIEW executable which houses the memory manager and you have most of what you need from the circular buffer example I linked to. Job done. I'll go to lunch.

One step at a time. Something about bridges and crossing them. After all. You have eloquently outlined the fall-back position.

Why have a work-around when you can have a solution?

You could implement it using the LabVIEW memory manager but it's not for the faint-at-heart. I once played with it for a circular buffer which isn't a million miles away from what you need. Oooh. Look. Words similar

Yes. That look familiar with windows forms. I've just been playing a bit more. I think there are messages posted to the thread from LabVIEW. PeekMessage will return messages targeted towards the thread (HWND = -1) and I thought I saw a 12 (WM_QUIT) from the LabVIEW Pid. Difficult to catch messages when you don't know what's being sent and Monte Carlo-ing in the debugger. I'll probably end up just logging them all to a file, but that will have to be next weekend. It'd be nice if it were just a case of peeking and then terminating on a WM_QUIT or our own ABORT

Yes. I understand and, as I said, I've used that in TCP. However. That's the user solving our problem and puts an onus on the user that I believe we can alleviate. There is a reason that NI specifically name a message pump for the UI thread. Basically I think that is only half a story.

Abort doesn't get actioned until the function returns since (as you rightly said) the callbacks run in the root loop. The function blocks the Abort callback until it returns. At that point, both abort and unreserve are actioned. So you cannot set an abort flag in your function when Abort is pressed. You can see this in the example if you set the nodes to UI thread and is why you need the message pump (I presume).

Only thing got from most of the companies I worked for was a pen set when I left.

I do this for TCP but what if I create a new HDC in the DLL node? Ala New(HDC), Draw(HDC), Close(HDC). The HDC must be accessed in the Root-loop so the Abort callback for New(HDC) would free it when Abort was pressed. Otherwise Close may never get called to free it.

Two reasons. Fully document the behaviour and operation as it allows us to do it.. Freeing resources that must be in the root loop (fonts or HDC's , for example). If you are referring to message pass-throughs where the message is allowed to continue on it's journey, it's what's required for form inspector tools so I've done that before (long time ago though). If that's what is required then it's fairly straight forward (famous last words ) The thing I'm not sure about is the hooking of the invisible LabVIEW window rather than the VI FP.

Here's a documented example with what I know (or think I know) so far. It may be a good starting point to fully flesh out the bahaviours without everyone reinventing the wheel. It's a work-in-progress as I learn more from this thread and discover the nuances. CLFN Callbacks.zip

Oh boy. This got complicated quickly Most modes of operation are per node (including UI) except run as clone which seems to be per thread. I'm not sure how that interacts with execution systems and execution systems across multiple VI's ATM. Running in the UI thread we obviously need "message pumping" for abort as per the dialogue that pops up. I presume this is referring to the the windows messaging to the form but may be wrong. I roughly know how to do this to normal windows forms and register user messages but without the main LabVIEW window refnum, I'm not sure how that would work. Anyone know what that looks like? Does anyone have a short example?

What's the scope of the InstanceDataPtr when run in User Thread? Does it behave like a LabVIEW-wide global pointer? VI-wide pointer (execution threads etc)? Or does LabVIEW still assign it a pointer local to the node?

Hmm. The returns from those functions seem to get eaten. Passing a mgErr back doesn't seem to do much. I would have thought they would appear at the error out of the CLFN. It'd be quite nice to report a "Canceled by user" error when Abort is called.

Indeed. It's all working great now. Thanks all for the help. When I get 5 mins I'll put together a working demo project and post it here.