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.
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. ;-)
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.
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.
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.
There are no comments made yet.
There are no replies made for this question yet. However, you are not allowed to reply to this question.
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here. Register Here »