drjdpowell

I didn’t get the OOP reference, and don’t want the casual reader to think that “Futures” are an OOP concept. They’re a Dataflow concept. We don’t have “Futures” explicitly in LabVIEW, because every wire is implicitly a future.

My “reply addresses” in “Messenger Library” are also actually callbacks. Callbacks are very flexible. Just as a note, my experience with “futures” (or “Write-once, destroy-on-reading Queues” as they are implemented as) is that I mostly use them to easily implement the Scatter-Gather messaging pattern, plus occasionally a Resequencer. Both come up when one is interacting with multiple loops, and reply messages can arrive in arbitrary order. “Future tokens” allow enforcement of a specified order.

Searching “Futures” implementations in other languages, I couldn’t find a standard set of terms. Some even used the generic and non-evocative “Get” for the part where one waits for a future to become an actual thing. So I’ll stick with redeeming my tokens. Thanks.

Does anyone else use “Futures”-like features in their code? If so, a question about terminology. Four years after this conversation “Future Tokens” are a significant part my reuse code (“Messenger Library”) and I use them often for handling multiple “actor” loops as arrays. I was just reading the docs for the Akka actor extension for Java and Scala and they use slightly terminology for their equivalent feature. They “await” a “future”, while I “redeem” a "future token”. Which is better or more intuitive? I like “token” because this is a physical thing that represents something else (a message) that has yet to exist. But I like “await” because it stresses the fact that we block until the message actually arrives.

Yep. Right-click on Combo box (inside cluster) and Create>>Property Node>>Strings[]

I just tried it and I had no problem making property nodes for a combo box inside a cluster.

The lock will be being caused by something else than the code being blocked, so you should post the rest of your code. Are you properly closing the “SQLite Connection” when finished with it? Leaving a transaction uncommitted? A Prepared Statement unreleased? BTW, you don’t need the BEGIN/COMMIT VIs in that code, as it’s only one SQL statement.

All the functionality is in those two poly VIs (personally, I’d prefer a more spread-out pallet). There are a few examples installed with the package.

I’ve been doing Approach #1. I haven’t encountered the problem you mentioned, though.

2009 is what OpenG is currently in, I think, so recursion should work.

Google suggests 8.5 for recursion with Dynamic Dispatch VIs and 2009 for any VI.

But I have direct recursion, not via VI Server, in packages in 2011 (example: Shortcut Menu from Cluster), and, at least in LVOOP classes, I had recursive calls in LabVIEW 8.6. OpenG uses VI Server because it was written well before that.

Does it require 2012? I thought recursion worked well before that.

The latest version contains an example, "Changing Icon on Flatline Button.vi” which contains instructions on how to substitute your own icons into the provided icon buttons (which all start with a “save” icon). I did this, rather than provide a suite of ready-made buttons, because there are just too many types and styles of icons.

I’ve been working on a wrapper for libpq.dll, which theoretically could be made to work on Linux by just using a libpq.so file, but I have only tried Windows so far.

I’ll call this beta if you want to give it a try: jdp_science_jsontext-0.2.0.9.vip BSD license.

I find the biggest improvement with Flat design is in the simplest of front panels. Here's a dialog box: Here I just used link-style buttons (the square around "Save as.." is placed by LabVIEW as it is bound to the Enter key). I eliminated the window tittle normally on the window frame, and instead placed that text in bold. This makes a very clear, uncluttered dialog box.

Do you know how to Customise controls? To get mouse-hover effects, I based these buttons on the System controls, which do not support different colours for ON/OFF states. So I instead made the ON state a 4x4 pixel PNG (like the hover states). If you install Bitman from the LAVA-CR, you can use the utility I used to make these PNGs: <LabVIEW>\vi.lib\drjdpowell\Flatline Controls\Utilities\Make small transparent square in PNG.vi Set your desired colour and Alpha transparency (I use a slightly higher Alpha for the Hover states. You can see the "pallet" of colours I used in: <LabVIEW>\vi.lib\drjdpowell\Flatline Controls\Button Pallet.vi To actually use your new transparencies, I'm afraid you have to manually customise the control and swap in the new PNG for the old in the ON state. If you Google you can probably fine a tutorial. Once you learn it it's not that hard.

Here is a demo button based on Silver buttons (instead of system buttons). No hover effects, but one can colour ON and OFF state differently, which you can't with system buttons. Flatline Non-hover button.vi

Oh, that enumeration. Not sure that would be on the list as only one thing can be written to a file at one time, even by TDMS. SQLite is by default ACID compliant (now that would be on the list), but one can turn that off to get asynchronous disk writes, just like TDMS. And as long as you writes are faster than your busy-handler timeout (I set that at 5 seconds, adjustable) then there are no Busy(5) errors. The issue is just write speed, where TDMS wins.

Sorry, what “enumeration”?

No, seems to work fine without that, as long as one reading, not writing.

Actually, at least up to the 2GB files I’ve tested, the SQLite file gets held in memory by Windows File Cache, so refreshing is fast (though the initial read will be slower with an HDD than an SSD, as will be writing).

TDMS is much more specialised than the more general-purpose SQLite. If your use case is well within what it is designed for (and it sounds like it is) then it is likely the better choice.

You didn't make them from scratch; you used available components (such as lawnmowers, brakes, engines, etc.) all of which you accepted as not being sabotaged by someone who wanted to kill you. An MOT is a non-onerous test, involving a reasonable set of requirements, so that sounds like a good idea. It would be a LOT of work to pass an MOT without using components manufactured by other people.