RESOLVED!
The problem was indeed due to having autoinstantiated NVOs being accessed in U_NV_AUTORPTS.

Thank you to Marc Wietscher and all those who helped me with this problem.

Details
As it turns out, I had several objects that were AutoInstantiated (AI) in the primary NVO "U_NV_AUTORPTS", as well as some indirect AI NVOs. We also had a global variable "n_cst_calculator   gnc_calc" that was autoinstantiated.

For most of the relevant AI NVOs I simply removed the autoinstantiated property. I then found where those NVOs were used and created the appropriate instance variables.

The N_CST_CALCULATOR error? That was caused by a global variable in the ancestor of the application object. I deleted that declaration and created that particular NVO as an instance variable where required.

I also use the PFC service N_CST_STRING quite a bit in U_NV_AURORPT, and yes, it's an AI NVO. I created a  new non-autoinstantiated NVO called U_NV_STRING and copied the functions that I use from the PFC NVO into my non-AI NVO, and used U_NV_STRING in U_NV_AUTORPT.

Holding my breath, I tested again and got a SUCCESS! return code from both of these calls:

    // Multi-threaded invocation
    lret_rc = SharedObjectRegister ("u_nv_autorpt", "AutoRpts")
    IF (lret_rc = SUCCESS!) THEN
    
        lret_rc = SharedObjectGet ("AutoRpts", inv_autorpt)    
        IF (lret_rc = SUCCESS!) THEN
          ....


Thank you all again!

Olan "the muli-threading code creator"  :)

1) I did find an auto-instantiatied object in U_NV_AUTORPT (n_cst_prfrnc).
        I changed this object to non-autoinstantiated.

2) I am not able to step into the call:
                lret_rc = SharedObjectRegister ("u_nv_autorpt", "AutoRpts")

    Running in debug mode when the line above is reached, I have a breakpoint in the constructor event of U_NV_AUTORPT and I do not hit that breakpoint. I also put a breakpoint in the constructor event of n_cst_calculator

3) U_NV_AUTORPT:
   a) is inherited from nonvisualobject
   b) is part of my PFC_based application
   d) calls various functions in GNV_APP (get userid, get debug flag, etc)   e) n_cst_calculator is neither declared nor used in this object - but it IS autoinstantiated
   f)  components are located:
          main.pbl - gnv_app (app manager), frame window (invokes U_NV_AUTORPT and stops it)
          corp.pbl - using u_nv_filesrv (get all files in a folder) and n_cst_prfrnc (get data from a table)
          rpt.pbl   - u_nv_autorpt and all associated components

4) I have downloaded Chris Pollach's multi-threading example and will look at it in detail.
         https://sourceforge.net/projects/stdfndclass/files/Applications/PowerBuilder/MutiThread

I'll report back when progress has been made.


Thank You All,

Olan

Hi Olan;

  This is hard to diagnose your issue(s) from these little code snippets. We would need to look deeper into your entire code design & use.

   I did a conference presentation on multi-threading that you might find interesting ...

https://sourceforge.net/projects/stdfndclass/files/Presentations/Multi-Threading

  Also, I have a multi-threading example that you can study as well ...

https://sourceforge.net/projects/stdfndclass/files/Applications/PowerBuilder/MutiThread

Note: In the "Archive" sub-folder, you can download a PB 12.x version of the multi-thread example App for your current PB 12.1 IDE.

HTH

Regards ... Chris

Hi Olan,

check your application for auto-instantiated global objects. In previous PB versions these caused crashes when trying to work with Shared Objects.

Your first error message hints to a constructor event of a non-related object.

Is n_cst_calculator declared globally and is is auto-instantiated?

BTW if there is no code in constructor event, even an empty line or a comment in this constructor event might crash your app when trying to register a shared object.

I can't remember with which PB version this was fixed, but it might have been 12.6.

Best regards

Marc

Hi Olan,

There's a working sample on this link: https://community.appeon.com/index.php/qna/q-a/how-do-i-can-to-use-sqlca-with-threads-sharedobject#reply-17151

I'm not sure if your problem might have something to do with having to separate objects into a separate library.

Also, your library list that you specify has to be complete enough for it to have all the objects compile.

Any global functions in used dw's?

HIH, regards.

Strange!

I expect you also do SharedObjectGet before accessing the NVO, Registration is kind-of like registering classes/objects with IOC container before Dependency Injection delivers you instance of that class when you code requests it.

What happens in line 7 of that constructor?

HTH /Michael