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.

On 4/27/2026 at 9:13 AM, Ady said:

Is it sufficient to replace the SQLite DLL with an encrypted build?

Are additional API calls (e.g. sqlite3_key) needed in LabVIEW?

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.

On 6/23/2025 at 11:38 AM, ionpol said:

Unfortunately, it fails. The original error I posted is from within the MATH.vi so it would make sense that nothing downstream of that would work.

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.

On 4/2/2026 at 7:05 PM, Thang Nguyen said:

we just changed the version of SQLite from 1.7.3.65 to 1.16.0.115 and we found out this library have a bug, we believe. This happen when we try to query a record cluster including enum value. In the Execute SQL (Variant Cluster results).vi/Parse Parameters.vi, originally, the enum is return as Int; now it returns as String.

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

11 hours ago, Dpeter said:

I wonder if it is because the DVR section is not a type def or a strict type def.

Does making it a typedef prevent the problem?

1 hour ago, ciozi137 said:

When I added the existing PQ classes to PQ.lvlib I had to fix an error inside "Connection Record.vi" unbundle to get the DVR.

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.

7 hours ago, codcoder said:

if there is an error in to the Write to Text File the file refnum becomes invalid

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.

On 7/29/2024 at 2:58 PM, Sam Dexter said:

Dear colleagues and Dr. Powell (hopefully),

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.

On 11/10/2023 at 2:09 PM, ciozi137 said:

Sounds good. I will make pull requests as I work through the open issues. I'll stay with LV 2017 for now per updates from @Antoine Chalons

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.