DISP_E_UNKNOWNNAME from GetIDsOfNames - COM Discussion Boards

Re: WorkBooks::OpenText file not loading

28-Feb-13 22:47

ForNow wrote:
Filename is Of type LPCTSTR

Then you should provide a LPCTSTR in your call, rather than providing a LPCSTR, and then telling the compiler to ignore the fact that the string may not be in the correct format. Lookup the use of the TEXT() macro and make sure your strings are generated correctly, and read the documentation on the correct use of casts.

Use the best guess

ForNow1-Mar-13 9:20

Re: WorkBooks::OpenText file not loading

1-Mar-13 9:20

The Text macro interperts the string if ansi is defined according to the current codepage

I think the string I am passing is being interpetted correctly

looking at the varaint type of the file it was being interpetted as a VT_BSTR

and had the correct value

C++

case VT_BSTR:
                {
                    LPCOLESTR lpsz = va_arg(argList, LPOLESTR);
                    pArg->bstrVal = ::SysAllocString(lpsz);
                    if (lpsz != NULL && pArg->bstrVal == NULL)
                        AfxThrowMemoryException();

Richard MacCutchan2-Mar-13 0:46

DISP_E_EXCEPTION & excepinfo->scode 800A03EC from WorkBooks::OpenText

2-Mar-13 0:46

ForNow wrote:
I think the string I am passing is being interpetted correctly

By luck, not judgement; if your project is built in UNICODE mode then it will be wrong. You should not use a cast unless you understand the consequences. Instead, use the TEXT() macro to ensure that your character string is generated in the appropriate character set to match the build. Your cast in the foregoing code is telling the compiler to ignore the fact that the string may be in the wrong character set.

Use the best guess

ForNow6-Feb-13 13:26

Re: DISP_E_EXCEPTION & excepinfo->scode 800A03EC from WorkBooks::OpenText

6-Feb-13 13:26

I am getting the above error from WorkBooks::OpenText

As all of the 18 paramters are optional
besides the first

I VT_NULL'ed all of them besdies the file name and still got the error

Since there is a lot of security where I work

I used the program name as the text file and still got the above errors

Any Help would be appreciated

Richard MacCutchan6-Feb-13 23:34

WorkBooks::OpenText failure

6-Feb-13 23:34

You should make an effort to research error codes first: see here[^] for a number of possibilities.

ForNow5-Feb-13 12:25

Re: WorkBooks::OpenText failure

5-Feb-13 12:25

Hi,

I am get an assert error when calling WorkBooks::OpenText

I traced it down the code to dispatch->invoke and the return code from that

was 0x80020008 DISP_E_BADVARTYPE One of the arguments in rgvarg is not a valid variant type.

I had a VARIANT for all my arguments besides the 5th which is a long

My question is then the following almost all the paramters are optional

besdides the first which is the filename

I assumed optional was a NULL so.

I coded the following for NULL

VARIANT varfalse.

varfalse.intVal = 0;
varfalse.vt = VT_INT;

is this correct ?

thanks

.

Garth J Lancaster5-Feb-13 15:47

Garth J Lancaster

5-Feb-13 15:47

ForNow wrote:
is this correct ?

no ... you should use

C++

varfalse.vt = VT_EMPTY

C++

varfalse.vt = VT_NULL

DISP_E_UNKNOWNNAME from GetIDsOfNames

ForNow29-Jan-13 15:04

29-Jan-13 15:04

Hi,

I getting the above return code the following is my code sequence

CLSID clsid;         // initialization
	HRESULT hr = CLSIDFromProgID(L"Excel.Application",&clsid)

IDispatch *pWApp;


	hr = CoCreateInstance(clsid, NULL, CLSCTX_LOCAL_SERVER, 
                          IID_IDispatch, (void **)&pWApp);

   LPOLESTR ptName = (LPOLESTR) _T("OpenText");
DISPID dispID;
 hr =  pWApp->GetIDsOfNames(IID_NULL, &ptName, 1 , LOCALE_USER_DEFAULT,&dispID);

I am using VIsual C++ 6.0 excel 2003

Thanks

Richard MacCutchan29-Jan-13 22:16

29-Jan-13 22:16

Check your return codes.

ForNow30-Jan-13 9:36

30-Jan-13 9:36

For CoInitialize I am getting a 0x00000001 S_FALSE (already initliazed)

For CLSIDFromProgID I am getting a 0x00000000 S_OK

For CoCreateInstance I am getting a 0x00000000 S_OK

For GetIDsOfNames I am getting a 0X80020006 DISP_E_UNKNOWNNAME

Thanks

Richard MacCutchan30-Jan-13 10:35

30-Jan-13 10:35

I have tried this code with a variety of names (supposedly in Excel) but get the same response each time. The MSDN documentation is not very helpful so I'm not sure where to go from here. However, once again I would ask, what problem are you actually trying to solve?

Richard MacCutchan30-Jan-13 10:39

30-Jan-13 10:39

I just tried again with the name "worksheets" and it worked. So, the code is correct, but the name you are using is not.

ForNow30-Jan-13 10:58

30-Jan-13 10:58

Very good you are right on the key is the first paramter

_In_ LPCOLESTR lpszProgID,

The Class id name, Excel is divded into for objects Application, Workbook, Worksheet, and I think Range

In Visual C++ 6.0 there is a OLE/COM viewer which might kind a hint of the names

What I am trying to do,

My boss gave me an assignment to automate the pasting of .txt file onto a Excel Worksheet

I wanted this app to be MFC based as I might need to employ windows services

Hence the main thread CWinApp and associated mainwindow

Thanks again for your help

Richard MacCutchan30-Jan-13 11:10

Found the Answer PLease Read

30-Jan-13 11:10

A quick search for "Excel C++" finds Accessing Excel Spreadsheets via C++[^].

ForNow30-Jan-13 11:34

30-Jan-13 11:34

Richard,

I have to wait for years here to get a better compiler e.g. Visual Studio

However Visual C++ 6.0 has an OLE/COM viewer

So......

From File -> Run the Registry Editor

Then get the progid

http://msdn.microsoft.com/en-us/library/aa911706.aspx[^]

ForNow30-Jan-13 15:51

30-Jan-13 15:51

I am going to go with the method you pointed out had using AS i GET BY THE
DISP_E_UNKNOWN

Maybe the way excel was installed it ddn't make entries

for HKCR\Typlib for the excel methods properties

Thanks

Richard MacCutchan30-Jan-13 22:51

30-Jan-13 22:51

You can find (most of?) the names in the Excel object properties[^]; I don't know where you got "OpenText" from.

ForNow1-Feb-13 10:25

AppCrash Issue related to COM?

1-Feb-13 10:25

http://msdn.microsoft.com/en-us/library/microsoft.office.interop.excel.workbooks.opentext(d=printer,v=office.11).aspx[^]

When I orignally coded the app and used the #import method I didn't find which led me to use native OLE functions

Then I got stuck with GetIDSofnames

Now I found the api in my excel.h header must of overlooked

thanks

Tony Tullemans24-Jan-13 14:17

Tony Tullemans

24-Jan-13 14:17

Greetings!

I have a complex scheduling application written in VB.NET (.NET Framework 4.0) that must use a Data Access Layer consisting of a bunch of C++ DLLs which are in-turn accessed via a COM API library. Of course when the COM API is referenced in the VB.NET application an Interop Assembly is created by Visual Studio.

The problem I am having is that some users are experiencing an APPCRASH (c0000005 exception code) several times per day, but this only occurs if they have the my application open all of the time and they are continually moving between it and other apps (e.g. to MS Word or MS Outlook etc). The APPCRASH occurs as soon as the shift their focus back to my application. I do have a suspicion as to why this may be occurring but my lack of knowledge of the way in which Windows and the .NET Framework manage memory precludes me from being sure.

My suspicion is that when users are using other applications for some time, and Windows requires more memory for those other apps, that it caches my app’s memory to disk. When they return to my app then Windows loads it back into memory, but because I am using COM it is placing the COM related memory into a different address and then when my app attempts to access the COM objects then an Access Violation is occurring and hence the APPCRASH. The faulting module is nearly always the COM API library, but sometimes it is ntdll.dll or clr.dll.

Does this sound like a reasonable hypothesis? And if so, what are my options (if any) for resolving this?

Here are a sample of problem signature traces. Note that they do not all have the same faulting module.

Signature du problème :
Nom d’événement de problème: APPCRASH
Application Name: VM2305.EXE
Application Version: 2.1.0.5
Application Timestamp: 4f44820b
Fault Module Name: a4wcomex.dll
Fault Module Version: 6.0.0.0
Fault Module Timestamp: 4cfb1354
Exception Code: c0000005
Exception Offset: 0001de92
Version du système: 6.0.6002.2.2.0.768.3
Identificateur de paramètres régionaux: 3084

Problem signature:
Problem Event Name: APPCRASH
Application Name: VM2305.EXE
Application Version: 2.1.0.9
Application Timestamp: 4fa218fd
Fault Module Name: clr.dll
Fault Module Version: 4.0.30319.261
Fault Module Timestamp: 4ec9f6ff
Exception Code: c0000005
Exception Offset: 00020ed1
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 4105
Additional Information 1: 93e2
Additional Information 2: 93e2ab0171a7a6ff1415f9bd2ed3bdf7
Additional Information 3: be03
Additional Information 4: be03af409f1ea363e69fa074d659b668

Problem signature:
Problem Event Name: APPCRASH
Application Name: VM2305.EXE
Application Version: 2.1.0.10
Application Timestamp: 4faca846
Fault Module Name: StackHash_0a9e
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 08000400
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 3084
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Problem signature:
Problem Event Name: APPCRASH
Application Name: VM2305.EXE
Application Version: 2.1.0.10
Application Timestamp: 4faca846
Fault Module Name: StackHash_0a9e
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 41080414
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 3084
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Problem signature:
Problem Event Name: APPCRASH
Application Name: VM2305.EXE
Application Version: 2.1.0.16
Application Timestamp: 4fea898a
Fault Module Name: a4wcomex.dll
Fault Module Version: 6.0.0.0
Fault Module Timestamp: 4cfb1354
Exception Code: c0000005
Exception Offset: 0001de92
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 4105
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Richard MacCutchan25-Jan-13 0:01

25-Jan-13 0:01

Tony Tullemans wrote:
Does this sound like a reasonable hypothesis?

No. Why, because if this was the case we would expect to see crashes occurring everywhere and all the time. The only way to identify what is happening is to add some debug code to your application so you capture more information prior to the crashes occurring.

Tony Tullemans28-Jan-13 12:28

Tony Tullemans

28-Jan-13 12:28

Thanks for your reply Richard, but the problem is that the AccessViolationException very rarely ever occurs when the application is running within the VS development environment, and furthermore it does not occur on all client computers. The only common factors I have been able to establish is that (1) the user has had the program running for several hours, and (2) the user has just switched back to my application after using some other program.

I have come to this forum in the hope that anyone who may have experienced similar errors may give me some clue as to what to look for. I have literally spent over one hundred hours trying to debug this issue.

Richard MacCutchan28-Jan-13 23:32

28-Jan-13 23:32

You have my sympathy, but unfortunately the only way to track this sort of error is to add logging and debugging code to your application. I worked in technical support for many years and often saw problems such as you describe, and yes, they were extremely difficult to diagnose.