Prev: System Error &H80070057 "The parameter is incorrect"
Next: Passing integer value between two classes as ByRef
From: Rick Raisley on 23 Jul 2008 15:58
This is Windows, right? So I know I can. But I'm not sure how:

I want my program to start up using a local data file (about 10 MB in size),
so operation can be quick, and then, in the background, check for and copy
an updated version of the file for use later while still using the program.
Locally, over our GB network, copying the file takes a fraction of a second.
When run from China, it can be an hour. My basic program structure will be:

In the Form_Load of the program I want to:

1) Read local data file.
2) Call/Start GetNewData to get and updated data file.
3) Continue running the program normally.
4) When the copied data file is available, update the program's data.

Here's the basic Subroutine:

Sub GetNewData()
If FileExists(Drive$ & "directory.tmp") Then Kill Drive$ &
"directory.tmp"
FileCopy DirFile$, Drive$ & "directory.tmp"
If FileExists(Drive$ & "directory.txt") Then Kill Drive$ &
"directory.txt"
Name Drive$ & "directory.tmp" As Drive$ & "directory.txt"
End Sub

The problem is that when called in the Form_Load sub, program execution
stops while the GetNewData sub is run, potentially resulting in a long
delay. What I'm wanting to do is START the GetNewData sub, and let it run in
the background, while the program continues. Then, after the new data copy
is complete, I can read it into the program automatically.

So, how do I START the sub containing the FileCopy command (or any other
lengthy operation, for that matter), without stopping the program from doing
other things in the meantime? I've thought of using a Timer; let the main
program just turn on the Timer, and continue on its merry way, while the
file copies in the background. That would work, I'm sure, but it seems like
there should be a better way. Ideas?

Another question: While the FileCopy is running, since I can't place any
DoEvents in it or anything, will it stop the rest of the program from
running, while it's actually copying the file (which, as I mentioned, can
take a long time)?

Any other suggestions are welcomed as well. ;-)

--
Regards,

Rick Raisley
heavymetal-A-T-bellsouth-D-O-T-net


From: dpb on 23 Jul 2008 16:19
Rick Raisley wrote:
....
> I want my program to start up using a local data file (about 10 MB in size),
> so operation can be quick, and then, in the background, check for and copy
> an updated version of the file for use later while still using the program.
....
> ... What I'm wanting to do is START the GetNewData sub, and let it run in
> the background, while the program continues. Then, after the new data copy
> is complete, I can read it into the program automatically.
....

The easiest would be to Shell to a DOS session and COPY the file.

Alternatively, write a separate task that does it and use the Win32
threads facility to launch it.

--
From: Rick Raisley on 23 Jul 2008 16:34
"dpb" <none(a)non.net> wrote in message news:g683t9$2pa$1(a)aioe.org...
> Rick Raisley wrote:
> ...
>> I want my program to start up using a local data file (about 10 MB in
>> size), so operation can be quick, and then, in the background, check for
>> and copy an updated version of the file for use later while still using
>> the program.
> ...
>> ... What I'm wanting to do is START the GetNewData sub, and let it run in
>> the background, while the program continues. Then, after the new data
>> copy is complete, I can read it into the program automatically.
> ...
>
> The easiest would be to Shell to a DOS session and COPY the file.
>
> Alternatively, write a separate task that does it and use the Win32
> threads facility to launch it.
>

I was trying to avoid Shelling out to Copy, not considering that as
"reliable". I did a test with a Timer, and while the tasks in the Timer can
go their merry way while my program is executing, the FileCopy command does
stop things dead while it's running. Meaning for this to work in the
background, it pretty much HAS to be executed by a separate program, be that
a DOS Shell or a Win32 thread as you suggest.

I'm not familiar with the "Win32 threads facility"; you aren't referring to
a separate, compiled program that is called (via Shell) from the main
program, are you?

Darn, I was REALLY hoping to keep this all within the program, as as soon as
the new file is copied, I want to read it into the main program's data. If
that is done by a separate program, I'll have to write a log file, and
constantly check the log file for its completion. :-(

--
Regards,

Rick Raisley
heavymetal-A-T-bellsouth-D-O-T-net


From: Jeff Johnson on 23 Jul 2008 17:10
"Rick Raisley" <heavymetal-A-T-bellsouth-D-O-Tnet> wrote in message
news:eJG08OQ7IHA.4652(a)TK2MSFTNGP05.phx.gbl...

> I'm not familiar with the "Win32 threads facility"; you aren't referring
> to a separate, compiled program that is called (via Shell) from the main
> program, are you?

He meant use real threading via API calls, since VB doesn't support
threading (unfortunately). It's not pretty, but it's the only way to get the
background processing you're looking for.

For all intents and purposes, you can't do what you're trying to do. Unless
you can find an ActiveX control that supports this sort of asynchronous
stuff.


From: kpg on 23 Jul 2008 17:30
> Darn, I was REALLY hoping to keep this all within the program, as as
> soon as the new file is copied, I want to read it into the main
> program's data. If that is done by a separate program, I'll have to
> write a log file, and constantly check the log file for its
> completion. :-(


You could try dh_threadpool.

I've used it before and it worked well for adding multi-threading
capability to vb6.

This link is pretty old but it still works.

http://www.datenhaus.de/Downloads/dh_ThreadPool.zip

The author has a nice little sample vb app showing what can be done
(quite eaisily I might add). No German required.


kpg
 |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: System Error &H80070057 "The parameter is incorrect"
Next: Passing integer value between two classes as ByRef