VBA in MS Word and MS Access different (use of external COM objects)

[Patrik Sj?gren]

Hi,
We have a COM object, which in turn use DDE to communicate with
another application of ours. Access to this COM object works fine
from C++, Visual Basic applications, VBS and VBA from MS Word.
But the the same VBA code that works in Word fails in MS Access.

Are there any differences in how VBA in MS Access use COM objects?
Should a COM object be ceated in any special manner to be able to
be used from MS Access?

thanks/Patrik Sjögren

[Stephen Lebans]

Most of the idiosyncrasies of the Access host container are documented
via a couple of MS KB articles. Of the couple of ActiveX controls I have
created with C++ the main issues I have run into have had to do with how
Access redraws itself and its controls. Additionally, some host
container props are not available when your control is first
initialized.

Where exactly is your code failing?

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"Patrik Sj?gren" <pa****@sectra.se> wrote in message
news:3d*************************@posting.google.co m...

Hi,
We have a COM object, which in turn use DDE to communicate with
another application of ours. Access to this COM object works fine
from C++, Visual Basic applications, VBS and VBA from MS Word.
But the the same VBA code that works in Word fails in MS Access.

Are there any differences in how VBA in MS Access use COM objects?
Should a COM object be ceated in any special manner to be able to
be used from MS Access?

thanks/Patrik Sjögren

[Patrik Sj?gren]

>

Where exactly is your code failing?

Hi,
First of all, our COM object is not a GUI object. All it contains is
around
20 methods that use BSTR to send and receive information, e.g:

virtual /* [helpstring][id] */ HRESULT STDMETHODCALLTYPE
PACSGetVersion(
/* [retval][out] */ BSTR *version) = 0;

The methods in the COM object in turn calls a corresponding DDE
function
of our applications to exchange information. The data returned through
the DDE interface is correct, according to the logs. However, when the
VBA-code is run in MS Access, the returned information from the DDE
call, in this case "PACS_version<1.4>", is replaced with "Error"
before arriving to our
COM object. So, MS Access somehow corrupts the information received
via DDE
to our COM object before it arrives. The same VBA-code works fine when
run from MS Word.
The problem seems to be that MS Access somehow interferes with DDE
communication, and in our case even replaces data.

[Stephen Lebans]

Sorry Patrik, I have no direct experience in this area.
Have you tried creating a standard Windows DLL and call your code from
there just to eliminate any Access to DDE to COM issues?

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"Patrik Sj?gren" <pa****@sectra.se> wrote in message
news:3d**************************@posting.google.c om...

Where exactly is your code failing?

Hi,
First of all, our COM object is not a GUI object. All it contains is
around
20 methods that use BSTR to send and receive information, e.g:

virtual /* [helpstring][id] */ HRESULT STDMETHODCALLTYPE
PACSGetVersion(
/* [retval][out] */ BSTR *version) = 0;

The methods in the COM object in turn calls a corresponding DDE
function
of our applications to exchange information. The data returned through
the DDE interface is correct, according to the logs. However, when the
VBA-code is run in MS Access, the returned information from the DDE
call, in this case "PACS_version<1.4>", is replaced with "Error"
before arriving to our
COM object. So, MS Access somehow corrupts the information received
via DDE
to our COM object before it arrives. The same VBA-code works fine when
run from MS Word.
The problem seems to be that MS Access somehow interferes with DDE
communication, and in our case even replaces data.

[Tom van Stiphout]

On 16 Aug 2004 23:49:27 -0700, pa****@sectra.se (Patrik Sj?gren)
wrote:

Can you post the VBA declaration for the API call?

Also, is the DLL copying the received string to an internal buffer
before returning it, or is it acting as a "pass-through"? Perhaps a
code fragment would help.

-Tom.

Where exactly is your code failing?

Hi,
First of all, our COM object is not a GUI object. All it contains is
around
20 methods that use BSTR to send and receive information, e.g:

virtual /* [helpstring][id] */ HRESULT STDMETHODCALLTYPE
PACSGetVersion(
/* [retval][out] */ BSTR *version) = 0;

The methods in the COM object in turn calls a corresponding DDE
function
of our applications to exchange information. The data returned through
the DDE interface is correct, according to the logs. However, when the
VBA-code is run in MS Access, the returned information from the DDE
call, in this case "PACS_version<1.4>", is replaced with "Error"
before arriving to our
COM object. So, MS Access somehow corrupts the information received
via DDE
to our COM object before it arrives. The same VBA-code works fine when
run from MS Word.
The problem seems to be that MS Access somehow interferes with DDE
communication, and in our case even replaces data.

[Patrik Sj?gren]

> Can you post the VBA declaration for the API call?
I'm not sure what you mean here but here is some test VBA-code that calls
our DLL/COM object:

Dim obj
Set obj = CreateObject("Sectra_desktop_sync.SectraDesktopSyn c")
obj.PACSInitialize "ICH"
MsgBox (obj.PACSGetVersion)
MsgBox (obj.PACSIsConnected)
obj.PACSResetDisplayList
MsgBox "after reset display list"
obj.PACSAddToDisplayList "07052001095347", "VascSubtrMesen"
MsgBox "after add to display list"
obj.PACSShowDisplayList 3
MsgBox "ready"

Also, is the DLL copying the received string to an internal buffer
before returning it, or is it acting as a "pass-through"? Perhaps a
code fragment would help.

Our DLL copies the received string before calling SysFreeString(result);
However, the debug version we've written to investigate this problem
pops up a message box just after receiving the string.
The message box says it has received the string "Error" while our
DDE log shows that we have sent "Pacs_version<1.4>". So, somewhere
on the way MS Access replaces the data sent via DDE before it arrives
to our DLL/COM object.

/*
* Retreive version of the DDE interface from the IDS
*/
STDMETHODIMP
CSectraDesktopSync::PACSGetVersion(BSTR *version)
{
USES_CONVERSION;

if (version == NULL) {
return E_POINTER;
}

[Patrik Sj?gren]

More info:

I get the same result when placing a breakpoint in our application that
cause the DDE call from the DLL to halt. This triggers a timout in
MS Word/VB that releases after about 10-15 seconds and the result is
the same as in MS Access (with the difference that it returns immediately).
I.e. the returned string is "Error".

Could it be some initiation of DDE that needs to be done in MS Access?

[Tom van Stiphout]

On 18 Aug 2004 04:10:40 -0700, pa****@sectra.se (Patrik Sj?gren)
wrote:

Sorry, I was a bit dense last night. Indeed you are using an ActiveX
DLL, not a classic DLL (which would have a declaration for each
"API").
I can't see anything wrong. For debugging purposes, I would:
return "Test From GetVersion";

If you can prove with a breakpoint on the "return E_POINTER" line that
the content is the correct version number, and with a breakpoint or
MsgBox on the next line in VBA that an "error" result is received, I
would be very surprised. Yet that's what you're saying.

What I meant by the internal buffer is something like (sorry - rusty
on C++):
if (version == NULL) {
char[255] buf;
strcpy(buf, E_POINTER);
return buf;
}

-Tom.

Can you post the VBA declaration for the API call?

I'm not sure what you mean here but here is some test VBA-code that calls
our DLL/COM object:

Dim obj
Set obj = CreateObject("Sectra_desktop_sync.SectraDesktopSyn c")
obj.PACSInitialize "ICH"
MsgBox (obj.PACSGetVersion)
MsgBox (obj.PACSIsConnected)
obj.PACSResetDisplayList
MsgBox "after reset display list"
obj.PACSAddToDisplayList "07052001095347", "VascSubtrMesen"
MsgBox "after add to display list"
obj.PACSShowDisplayList 3
MsgBox "ready"

Also, is the DLL copying the received string to an internal buffer
before returning it, or is it acting as a "pass-through"? Perhaps a
code fragment would help.

Our DLL copies the received string before calling SysFreeString(result);
However, the debug version we've written to investigate this problem
pops up a message box just after receiving the string.
The message box says it has received the string "Error" while our
DDE log shows that we have sent "Pacs_version<1.4>". So, somewhere
on the way MS Access replaces the data sent via DDE before it arrives
to our DLL/COM object.

/*
* Retreive version of the DDE interface from the IDS
*/
STDMETHODIMP
CSectraDesktopSync::PACSGetVersion(BSTR *version)
{
USES_CONVERSION;

if (version == NULL) {
return E_POINTER;
}

[Patrik Sj?gren]

> If you can prove with a breakpoint on the "return E_POINTER" line that

the content is the correct version number, and with a breakpoint or
MsgBox on the next line in VBA that an "error" result is received, I
would be very surprised. Yet that's what you're saying.

What I meant by the internal buffer is something like (sorry - rusty
on C++):
if (version == NULL) {
char[255] buf;
strcpy(buf, E_POINTER);
return buf;
}

-Tom.

We have a "debug" version of our COM object that pops up a MsgBox
to show the contents of the returned string. In MS Access (VBA), this
is always "Error", while it is "PACS_Version<1.4>" in VB, MS Word
(VBA) etc.

However, I get the same result, i.e. "Error" when placing a breakpoint
in our application to prevent the DDE call from the COM object to
return. This triggers a timout in MS Word/VB that releases after about
10-15 seconds and the result is the same as in MS Access (with the
difference that it returns immediately). I.e. the returned string is
"Error".

Could it be some initialization of DDE that needs to be done in MS
Access?