Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (3)

Resolved Shared objects and global variables

  1. How-to
0
Votes
Undo
  1. Giuseppe moglia
    Giuseppe moglia
  2. PowerBuilder
  3. Friday, 17 September 2021 08:48 AM UTC

Hi Guys

 

we want to use multithread approach to improve some of our routines but we find out that in shared objects global variables are not valued

Is this a bug, a feature and how can we solve?

 

Thanks a lot

  1. Multi Threading
  2. PowerBuilder
Migration Issue - from PB 10.5
Issue with PowerBuilder Editor
Responses (3)
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Friday, 17 September 2021 14:50 PM UTC
  2. PowerBuilder
  3. # 1

Hi, Guiseppe -

Roland is correct. Not only does each shared object utilize their own copy of the app's global variables, they each get a copy of the initial state of the app's global variables...not the current state, but the initial values as when the application starts.

Also, because a shared object executes in a non-visual-capable thread, a shared object cannot have any direct interaction with a visual control (windows, DataWindows, buttons, static text, etc.). You need to use an intermediary NVO referred to as a callback object to interface between the shared object and any visual objects/controls.

I've developed and hope to soon publish on the Appeon Community a sample application that uses shared objects to perform a database retrieval and displays the retrieved data in a window's DataWindow, and I'm in the process of writing an article to explain how shared objects work, tips on do's and don'ts, but the article is not yet finished. I would be happy to supply you with an advance copy of the sample app and the current state of the article (word document) if you are interested.

Best regards, John

Comment
Load more comments
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Friday, 17 September 2021 16:29 PM UTC
Hi Roland;

Better yet, you can pass the address of any Window class to the "Client" NVUO which in turn, can then pas that address to the "Thread" NVUO. Once that occurs, the thread NVUO can then easily Post methods on the Window class *directly* and most importantly, pass any number of arguments of any data type that is supported by PB to the Window class (or any class that the address points to). Food for thought. ;-)

Regards ... Chris
  1. Helpful 1
John Fauss
  1. John Fauss
  2. Tuesday, 21 September 2021 18:42 PM UTC
Roland - Thank you!. Yes, you can register a window's handle in a shared object and use the PowerScript Send (or Post) functions to invoke events in the window, or use the SendMessageW and/or PostMessageW Windows API functions to do the same.



However, doing so limits you to invoking mapped (pbm_custom01-75) events only (no unmapped events and no functions) and you're also restricted as to the number of arguments and their types. If your development needs can be satisfied by those limitations, then by all means, use that technique if you wish.



A more generalized and flexible approach, IMHO, is to use a "callback" NVO as an intermediary between the shared object and the window. The article I'm writing will include a description of the technique you've used in your Winsock sample program (with attribution to you, of course) and I've coded one example that uses this technique in the multi-threaded data retrieval sample app that will accompany the article, because I think it's important for people to learn about both approaches so they can decide what works best for themselves.
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Tuesday, 21 September 2021 19:03 PM UTC
Yep .. that's what I was promoting! ;-)
  1. Helpful
There are no comments made yet.
Roland Smith
Roland Smith Accepted Answer Pending Moderation
  1. Friday, 17 September 2021 14:20 PM UTC
  2. PowerBuilder
  3. # 2

Each thread has it's own copy of the global variables. This is by design so you have to pass any data needed by the background thread from the main thread before posting the function call that does the background processing.

This means that each background thread has to establish its own connection to the database.

 

Comment
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Friday, 17 September 2021 14:47 PM UTC
  2. PowerBuilder
  3. # 3

Hi Giuseppe ;

  While you do have GV's in each thread, I would personally recommend that you never use them. Always use Instance variables instead. This will make your threads much more thread safe and you will (in my vast experience with threading) have a much more stable App. Just my $0.02.

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

Regards ... Chris

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.