Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread Threaded Function - Version #1
Thu, May 15 2014 9:34 PMPermanent Link

Adam H.

Relates to E.D.B.General->Writing a function that queries data in Thread

To run you will need to change the Main Units DatabaseLocation property
to where ever you extract this zip.



Attachments: ThreadedFunction.zip
Mon, May 19 2014 9:53 AMPermanent Link

Raul

Globestar Systems

Team Elevate Team Elevate

On 5/15/2014 9:34 PM, Adam H. wrote:
> Relates to E.D.B.General->Writing a function that queries data in Thread
>
> To run you will need to change the Main Units DatabaseLocation property
> to where ever you extract this zip.

My 2 versions :
1a is the one that uses on terminate
1b uses messages

See my reply post in the general NG

Raul




Attachments: ThreadedFunction_v1a.zip ThreadedFunction_v1b.zip
Mon, May 19 2014 10:46 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Raul

That saves me sone time Smiley


1b is pretty much what I would have done (written differently of course) with one significant exception. I prefer to define a number of error messages and not pass string pointers around - just personal preference.

Adam, I'd like to point out that Raul correctly disposes of the memory he allocates to the return message string. Failure to do so leads to leaks and the death penalty!

Roy Lambert
Mon, May 19 2014 11:51 AMPermanent Link

Raul

Globestar Systems

Team Elevate Team Elevate

On 5/19/2014 10:46 AM, Roy Lambert wrote:
> 1b is pretty much what I would have done (written differently of course) with one significant exception. I prefer to define a number of error messages and not pass string pointers around - just personal preference.

in that case you might be able to just use an int value and not bother
with the record at all.

In our case we use threads heavily for data comm (i.e. http, tcp sending
threads or hosting a tcp/http server) so string is still easiest way to
pass round the payload i've found (xml, json ,etc). especially once you
do a thread pool - the threads are generic and payload contains all the
info they require.


> Adam, I'd like to point out that Raul correctly disposes of the memory he allocates to the return message string. Failure to do so leads to leaks and the death penalty!

One thing i'm not doing is checking the PostMessage result. correct code
should check it and dispose of the record if sending failed. In real
world though this is very rare and recovery options from thread's
perspective are limited - you could retry sending or throw up an error
dialog (windows API MessageBox with nil parent is pretty much the only
option) and abort.

Raul
Tue, May 20 2014 3:06 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Raul


>One thing i'm not doing is checking the PostMessage result. correct code
>should check it and dispose of the record if sending failed. In real
>world though this is very rare and recovery options from thread's
>perspective are limited - you could retry sending or throw up an error
>dialog (windows API MessageBox with nil parent is pretty much the only
>option) and abort.

Its something I don't bother with mainly because without the receiving application sending a message back you have no way of knowing if its been handled anyway. I suppose you could go to SendMessage since at that point you're not to concerned  about keeping the thread running. I've never tried it so I have no idea what happens if the window the message is sent to has run away.

Roy
Image