drjdpowell

The automatic shutdown feature is implemented by a "watchdog", which watches for the launching actor to stop running and sends the message. This has the advantage that it always happens, even if the launching actor stops due to an out-of-memory error or hitting the stop button, but it has the disadvantage that shutdown happens only after the launching actor has stopped.

Here is an example from one of my Apps, where I shutdown multiple subactors (in an array) and wait for all to reply that they have fully shutdown (I'm using Scatter-Gather to allow all to shutdown in parallel):

I would suspect your problem is that your app closes the main window before its finished all its shutdown operations like your INI file. That is fine in source, but it is my understanding that Windows will kill a process with no open windows (Google is failing me on confirming that). Things to try: Command your subactors to shutdown and wait on their replies before stopping the top level actor and closing the main window. Then you know your subactors have executed their shutdown actions. If there is a reason you can't tell them to shutdown (and you have to rely on auto shutdown). Then you need to keep a window open until your code has a chance to execute it's cleanup, so Windows doesn't kill you first.

Hi, can anyone with experience with using Messenger Library on RT please have a look at this question and see if they can help: https://forums.ni.com/t5/JDP-Science-Tools/Issue-with-Child-Actors-on-cRIO/td-p/4484658 I'm afraid I haven't had an work on RT in years and have no access to an RT system to debug so I have difficulty helping.

Sorry I missed this. I'm afraid I have no time to work on PQ myself at the moment but I would happily look at your PR. Those all sound like features that wouldn't be problematic.

It's reasonably easy to use SQLCipher. Just pass in the dll and execute two SQL PRAGMAS, one with your license for SQLCipher and one with the database's key (https://www.zetetic.net/sqlcipher/sqlcipher-api/). No new calls are needed.

Sorry I never got back to you here. That error looks like the extention dll is missing. I would check to see if it is at the path specified in teh error message.

Mapping Enums onto SQLite Text type is intentional. The "Parameters" feature didn't exist back in version 1.7.3. Note that if you are converting data selected from the database, you can convert either Integer or Text as Enums, but with Paramaters (going into the database) one has to make a choice of type for Enums, and the choice I made is Text. You can still make Enums Integers, but you will have to use another method, such as "Prepare Statement".

JSON is always in UTF-8, and JSONtext will try and convert to your computer's character set automatically, so I don't think you need any of that stuff that has "UTF8". Try simply using the single function to convert to a 2D array of strings. However, by sure you are actually passing true JSON, with UTF8 encoding, not whatever your computer is using.

I checked that it works for me, in LabVIEW 2021. Does code this simple fail for you:

Does that DLL exist at the stated path?

Can you give an example VI showing the problem. It seems to work in teh current source code.

I think this is teh same issue as this: https://forums.ni.com/t5/JDP-Science-Tools/Cannot-Install-JDP-Science-Common-Utilities/m-p/4418396#M205 The SQLite package requires JDP Common Utilities, and that package seems to have a problem. Workaround is to download it and have VIPM install it directly, rather than try and get it from the Tools Network servers (it's a server issue, not a problem with the package itself). I'll attach it here as well. Try installing this and then retry installing SQLite. jdp_science_lib_common_utilities-1.4.1.18.vip

Does making it a typedef prevent the problem?

What was this error? I can't seem to reproduce it.

I will change the terminal name to "Format empty input as null" to prevent reading it as referring to JSON Strings in the input rather than the entire LabVIEW string. And I'l try and give a better description:

I confirmed the behaviour on my machine. It is that the Write doesn't pass the file reference through if there is an error in. Seems like a bug to me.

I just checked, and it doesn't close teh file reference, but it does pass out a null reference. The original reference is still valid. This is still unexpected behavior, though.

Yes, Queues don't make unnecessary copies, but User Events make two copies, so the EventDVRmessenger is just to work around that.

I have put some effort into improving the VI icons in Messenger Library, in hopes of making things clearer. I have particularly been trying to get rid of the magnifying glass icon, which was standing in for too many concepts. I have also tried to improve the Palettes by putting the standard VIs (that one would most commonly use) in the root-level palette: The 2.0 version also introduces Malleable API methods (the orange-coloured ones), which make code cleaner. If anyone could spare some time, it would help me to have feedback. Especially from people who have not used Messenger Library before, so I can get an idea if the key concepts come across. New 2.1.3 version is available here: https://forums.ni.com/t5/JDP-Science-Tools/New-icons-for-Messenger-Library/m-p/4412550#M192

I'm sorry, you posted just before I went on a full month of holiday and I never saw this. Do you still need help? Any further info?

Has anyone had a chance to use teh new version? At least as far as trying the new examples.

0.6.0 version now on VIPM: https://www.vipm.io/package/jdp_science_postgresql/ This involves significant improvements, as well as Examples that work with a public postgres server (and thus work without needing Postgres installed). I am hoping this is close to a 1.0 version.

I have published a 0.3.1 package on VIPM.io with Antoine's changes (LabVIEW 2017). Then I've accepted your Pull Requests and published a 0.4.0 version as well (LabVIEW 2019): https://www.vipm.io/package/jdp_science_postgresql/

I think your second point is wrong; VIs without the front panel loaded don't use any resources. EXEs don't even include the code for those front panels.