G
Guest
Hi,
I'm active in VC++ for several years now, so I know some things (I think).
Using MS-Access I store a db with lots of entries and uses the VBA
techniques to export those data to e.g. HTML, XML and other kind of data.
I'm using MS-VC++6.0-Enterprise (with sp6) at NT4-Workstation (sp6a) and
MS-Access97 (from MS-Office97). Reason that I won't upgrade to latest
Office/VisualStudio is that I must ensure that any application I develop
still works at Windows9x (and so on) - so for full compatibility with any
configuration.
Lately I ran into a problem, while I use an external function from a VC++
DLL (DLL build as a 'MFC Regular DLL' using dynamic linkage over MFC) to
export all my data in a fixed file (must use the DLL for performance, while I
first create a directory with files in VBA then use the functions inside the
DLL to grab the contents of the exported directory and put it all into a
bynarie file - it's intended to be used by an installation procedure for
customers).
The DLL creates a worker-thread in which it creates a modal-dialog box using
'DialogBoxIndirectParam'. This Dialog stays on top of the calling HWND until
it receives a message from the calling thread that it may close (using
'EndDialog').
From start-up until end of the dialog it receives custom message
(combinations of WM_USER) to display a progress-bar of the running thread.
This works fine when calling from a MFC-module (.exe) but appearently it
doesn't when called from MS-Access: the dialog popups, but halfway it stops
receiving messages and in rare cases it does handle all send messages, but
then it won't disapear from the desktop when the dll has finished.
I gues the problem is MS-Access, maybe it's STA (single threaded) while my
DLL is multi-threaded, so I would try another solution : sending the progress
messages directly to the calling Access module. But then I come into my
problem.
How can I let MS-Access react at my own 'custom' messages, while the VBA
module is still 'waiting' for my DLL to finish.
I already tried to develop a COM object, but while this asks a lot of
development it didn't resolve my problem!
If anyone would know a good suggestion/answer for me, I would appreciate it
very much. Currently I run the exported DLL-function in VBA without popping
up the progress dialog (Access is blocking anyway while my DLL is in
progress, and that can take up a very long time, while I've got a lot of data
in the DB), so Access won't react strange anymore.
I also tried to 'talk' directly to MS-Access by linking to the Access-COM
module in VC++ so I could try to get an interface to the Access.Application
object and so modify the statusbar, but as soon I do MS-Access popups with a
Kernel failure !?
So I come with my question, would it be possible to run my DLL-procedure in
a seperate thread, so Access can go into idle-status, so it could react to
custom messages I send from the DLL, so Access can write to the statusbar
itself...?
But is it possible at all, to launch a seperate thread in MS-Access? Or
should I better call a seperate thread from inside the DLL and then return
immediately so I could have MS-Access to go into a timer-loop (event
'OnTimer') - but then I still don't know how to react at custom messages from
my DLL.
Thank you very much if you can help me!
Laurens K.
I'm active in VC++ for several years now, so I know some things (I think).
Using MS-Access I store a db with lots of entries and uses the VBA
techniques to export those data to e.g. HTML, XML and other kind of data.
I'm using MS-VC++6.0-Enterprise (with sp6) at NT4-Workstation (sp6a) and
MS-Access97 (from MS-Office97). Reason that I won't upgrade to latest
Office/VisualStudio is that I must ensure that any application I develop
still works at Windows9x (and so on) - so for full compatibility with any
configuration.
Lately I ran into a problem, while I use an external function from a VC++
DLL (DLL build as a 'MFC Regular DLL' using dynamic linkage over MFC) to
export all my data in a fixed file (must use the DLL for performance, while I
first create a directory with files in VBA then use the functions inside the
DLL to grab the contents of the exported directory and put it all into a
bynarie file - it's intended to be used by an installation procedure for
customers).
The DLL creates a worker-thread in which it creates a modal-dialog box using
'DialogBoxIndirectParam'. This Dialog stays on top of the calling HWND until
it receives a message from the calling thread that it may close (using
'EndDialog').
From start-up until end of the dialog it receives custom message
(combinations of WM_USER) to display a progress-bar of the running thread.
This works fine when calling from a MFC-module (.exe) but appearently it
doesn't when called from MS-Access: the dialog popups, but halfway it stops
receiving messages and in rare cases it does handle all send messages, but
then it won't disapear from the desktop when the dll has finished.
I gues the problem is MS-Access, maybe it's STA (single threaded) while my
DLL is multi-threaded, so I would try another solution : sending the progress
messages directly to the calling Access module. But then I come into my
problem.
How can I let MS-Access react at my own 'custom' messages, while the VBA
module is still 'waiting' for my DLL to finish.
I already tried to develop a COM object, but while this asks a lot of
development it didn't resolve my problem!
If anyone would know a good suggestion/answer for me, I would appreciate it
very much. Currently I run the exported DLL-function in VBA without popping
up the progress dialog (Access is blocking anyway while my DLL is in
progress, and that can take up a very long time, while I've got a lot of data
in the DB), so Access won't react strange anymore.
I also tried to 'talk' directly to MS-Access by linking to the Access-COM
module in VC++ so I could try to get an interface to the Access.Application
object and so modify the statusbar, but as soon I do MS-Access popups with a
Kernel failure !?
So I come with my question, would it be possible to run my DLL-procedure in
a seperate thread, so Access can go into idle-status, so it could react to
custom messages I send from the DLL, so Access can write to the statusbar
itself...?
But is it possible at all, to launch a seperate thread in MS-Access? Or
should I better call a seperate thread from inside the DLL and then return
immediately so I could have MS-Access to go into a timer-loop (event
'OnTimer') - but then I still don't know how to react at custom messages from
my DLL.
Thank you very much if you can help me!
Laurens K.