Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread new (to) threads
Sun, Jul 1 2007 8:40 PMPermanent Link

"Monte Etherton"
Re: DBISAM v4.25.3 & D7

I have never implemented a TThread before, but I have what looks like a good
opportunity to use one in place of the "brute force" approach in use now
(set range & scan table in main thread while user waits for hourglass to
disappear).

I have not tried to code anything yet, because I don't know how...I'm just
gathering prelim info.  Thanks in advance for any advice on how to (and
whether to) proceed!

Here's a simplistic scenario:

dbMain: Invoice data records
dbNotes: Note records for each invoice (30K recordcount)

dbMain & dbNotes are both displayed in a master/detail grid, which is the
primary UI to this (multi-user) app.

Every 10 minutes, a timer triggers a scan of dbNotes for "timed notes".
These are note records that a user previously entered (usually as a future
reminder). Once the date/time of the "timed note" is current, the app then
sets a flag in the dbInvoice master record (so it is highlighted and the
user is notified), while also attaching the note as a new detail record.

Is this a good candidate for using a thread?

If I create a TThread to execute the scan on the timer trigger, I assume I
have to use different instances (created in the thread unit?) of each of the
tables, but do I also need a different session & database?

Once the thread terminates, is it then as simple as refreshing the UI
instances of both tables to get the record changes to show?

thanks again.

Monte



Mon, Jul 2 2007 3:00 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Monte


I'm slightly confused here. If you'e holding the date and time in a datetime field then a simple filter or range and checking .RecordCount is fast enough to find out if there are any records to be merged rather than a brute force scan.

That aside.

>Is this a good candidate for using a thread?

As good as many Smiley

>If I create a TThread to execute the scan on the timer trigger, I assume I
>have to use different instances (created in the thread unit?) of each of the
>tables, but do I also need a different session & database?

However you start the thread you need full isolation. This means separate database, session and tables UNLESS you can guarantee that ONLY the thread will ever touch them.

My approach would be to start the thread with the app, have it looping and set its terminate flag when the app is closed rather than to keep starting it with a timer.

There have been loads of posts in the borland ngs borland.public.delphi.language.delphi.win32 about this - its worth going to have a look.

>Once the thread terminates, is it then as simple as refreshing the UI
>instances of both tables to get the record changes to show?

Yes, but you'll have to send a message back to the main thread to do the refresh. You can't refresh them in the thread unless you use critical sections or synchronise and I'm not sure about that. Personally I PostMessage back to the main thread.

Roy Lambert
Tue, Jul 3 2007 12:27 AMPermanent Link

"Monte Etherton"
Thanks, Roy.

I do use a range, and have tried to make sure the routine is only fired when
the app is idle...but it still takes control away from the user for a couple
of seconds, and I thought using a thread would make it pretty much invisible
to the user.

So in your suggestion, the thread is continually running along side the main
app?  I was thinking that I could just create it when needed and then let it
go.  I'll do some more research on the ng's you mentioned.

Thanks again...perhaps I'll learn this is overkill for what I will gain.

-Monte

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:9D41A22F-C711-4643-8002-A2A8FD1F68C7@news.elevatesoft.com...
> Monte
>
>
> I'm slightly confused here. If you'e holding the date and time in a
> datetime field then a simple filter or range and checking .RecordCount is
> fast enough to find out if there are any records to be merged rather than
> a brute force scan.
>
> That aside.
>
>>Is this a good candidate for using a thread?
>
> As good as many Smiley
>
>>If I create a TThread to execute the scan on the timer trigger, I assume I
>>have to use different instances (created in the thread unit?) of each of
>>the
>>tables, but do I also need a different session & database?
>
> However you start the thread you need full isolation. This means separate
> database, session and tables UNLESS you can guarantee that ONLY the thread
> will ever touch them.
>
> My approach would be to start the thread with the app, have it looping and
> set its terminate flag when the app is closed rather than to keep starting
> it with a timer.
>
> There have been loads of posts in the borland ngs
> borland.public.delphi.language.delphi.win32 about this - its worth going
> to have a look.
>
>>Once the thread terminates, is it then as simple as refreshing the UI
>>instances of both tables to get the record changes to show?
>
> Yes, but you'll have to send a message back to the main thread to do the
> refresh. You can't refresh them in the thread unless you use critical
> sections or synchronise and I'm not sure about that. Personally I
> PostMessage back to the main thread.
>
> Roy Lambert
>

Tue, Jul 3 2007 2:31 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Monte

>So in your suggestion, the thread is continually running along side the main
>app? I was thinking that I could just create it when needed and then let it
>go. I'll do some more research on the ng's you mentioned.

You can, and in one app that's exactly what I do, but in that case the thread is triggered irregularly. You want one that runs regularly so its better to create it once and cycle it.

Roy Lambert
Tue, Jul 3 2007 3:31 AMPermanent Link

"Frans van Daalen"

"Monte Etherton" <monte[at-sign]automatedconceptsca[dot-char]com> wrote in
message news:E1186412-830F-42B0-B455-2048C6A4887A@news.elevatesoft.com...
> Thanks, Roy.
>
> I do use a range, and have tried to make sure the routine is only fired
> when the app is idle...but it still takes control away from the user for a
> couple of seconds, and I thought using a thread would make it pretty much
> invisible to the user.

If your thread take control away then some items used in the thread are not
created in the .execute event of the thread and therefor running in the
context of the main thread OR you are using synchronize in which case you
need to get rid of that one using some other way.

>
> So in your suggestion, the thread is continually running along side the
> main app?  I was thinking that I could just create it when needed and then
> let it go.  I'll do some more research on the ng's you mentioned.

creating and killing a thread is perfomance unwise hence his suggestion to
create it once and let it run. You can lose the timer by using loop in the
thread using a waitfor event

>
> Thanks again...perhaps I'll learn this is overkill for what I will gain.
>

Image