|
You mean a different GUID? Can a forward declaration have a GUID? Don't think so...
Why isn't everyone having this problem  ?
|
|
|
|
|
I do that all the time
[uuid(...
]
library MyCoolLib
{
interface IB;
[ object, uuid(...),dual...]
interface IA : IDispatch
{
[id(1), helpstring("")] HRESULT func([in] IB* pB);
};
[ object, uuid(...),dual...]
interface IB : IDispatch
{
[id(1), helpstring("")] HRESULT func([in] IA* pB);
};
|
|
|
|
|
I'm using the ATL Wizard in VS.NET which puts the IDL and C++ in the same file, so I have to use the __interface keyword, which I think is the problem because the MIDL compiler doesn't recognize the forward declaration using __interface. Maybe. Arrghh. 
|
|
|
|
|
I am facing the same problem and have not able to find out any solution yet. I tried inserting interface declaration statements in IDL file using "cpp_quote" attribute also but that does not work even (it inserts the line including "cpp_quote" 
Rowan, have you been able to find out any solution yet. If you had already, do post it... it would be a great help !
Thanx & Regards,
Arun.
|
|
|
|
|
Alas I've given up trying - but I'll remember to put it here if I ever fix it
|
|
|
|
|
I am working on developing a test application in java. I use java for UI only. I use JNI to communicate with a VC MFC DLL. I launch an IE browser instance in one JNI method (init()), which works fine.
OleInitialize(NULL);
CLSID clsid;
CLSIDFromProgID(OLESTR("InternetExplorer.Application"), &clsid);
HRESULT hr = CoCreateInstance(clsid, NULL, CLSCTX_LOCAL_SERVER, IID_IWebBrowser2, (void**)&m_spBrowser);
I store the browser pointer (IWebBrowser2 *) as a C++ class instance variable. BTW, I start a
thread on the native side (_beginthread) which in turn calls the method that launches the browser.
Previously I was facing the problem of marshalling, the IWebBrowser2 pointer was getting correupted, when used in different methods (even the simple properties of IWebBrowser2 (like IWebBrowser2::fullname) were not accessible). So now I have added the code of marshalling after the browser is launched. In almost all the other methods, I first unmarshall the interface and then marshall it back at the end of it. This solved my earlier mentioned problem.
void CIECanvas::MarshallInterface()
{
HRESULT hr;
if(SUCCEEDED(hr = ::CreateStreamOnHGlobal(NULL, TRUE, &pstm)))
{
LARGE_INTEGER bZero = {0, 0};
pstm->Seek(bZero, STREAM_SEEK_SET, NULL);
if(SUCCEEDED(::CoMarshalInterface(pstm, IID_IWebBrowser2, m_spBrowser, MSHCTX_INPROC, NULL, MSHLFLAGS_NORMAL)))
{
pstm->Seek(bZero, STREAM_SEEK_SET, NULL);
}
}
}
void CIECanvas::UnmarshallInterface()
{
LARGE_INTEGER bZero = {0, 0};
pstm->Seek(bZero, STREAM_SEEK_SET, NULL);
HRESULT hr = ::CoUnmarshalInterface(pstm, IID_IWebBrowser2, (void**)&m_spBrowser);
if(FAILED(hr))
{
showMessageBox("CIECanvas::UnmarshallInterface()", "%s %ld", "FAILED. ERROR CODE = ", GetLastError());
}
}
Then for recording I use AfxConnectionAdvise(), which is working fine.
The problem I am facing is in Replaying the events.
1)The VM crashes with a hotspot error, when on the first page some link click event is present, which loads a new page. One observation here is the VM crashes after onBeforeNavigate2 or TitleChange events are fired.
2)I also tried Yahoo's registration page (having a lot of dropdowns and checkboxes), it works fine for the first few events, but then the VM crashes.
My questions are
1)Does IE handle the events like page loading (tiltle change etc.) and click on some link in different threads? How are the events handled (any useful info on this)?
2)How should I fix the problem?
3)Is it related to marshalling of IE COM pointers?
Please replay ASAP,
Nikhil
|
|
|
|
|
Ok, some more findings on this. This is most probably happening because of async message processing by IE and my native class. By the time the IE event is fired by the native class is finished, IE has already started processing it. How can I stop IE from doing this (previously I had embedded webbrowser control embedded in a Java canvas and I was using PostMessage() for firing IE event, I guess this was working because, IE event processing was started only after the firing of event was finished, am I right?)
|
|
|
|
|
Hi, all:
I have a weird problem and need your help. I have a main app and DLL. In the main app I have my object pointer (CMyObj* pObj) that has method like:
HRESULT TranslateIDToName( long lID, LPSTR cBuff, UNIT dwBuffSize );
this TranslateIDToName then calls some methods in DLL.
In main, I have something like this:
const DWORD dwBuffSize = 128;
TCHAR cBuff[dwBuffSize];
pObj->TranslateIDToName( lID, cBuff, dwBuffSize );
When I compile both main app and DLL in RELEASE, (both uses Multithreaded DLL as Runtime DLL ). It works fine! However, if I compile both in Debug ( both uses Debug Multithreaded DLL ), I step through the code, The TranslateIDToName() fills up the cBuff correctly and then return from the function.
The problem comes when the function returns to the caller:
pObj->TranslateIDToName( lID, cBuff, dwBuffSize );
The pObj is trashed with either garbage in the pObj or pObj = NULL. In either case, the pObj address changes before calling the method and right after return from the method ( the Stack really messed up!!). Of course, the app crashes!
I tried all the stuff I can think of, and no more ideas about what could be wrong.
Any suggestion and help will be highly appreciated. Thanks in advance.
Dion
|
|
|
|
|
How to pass VBA Collection to COM DLL from .NET C#?
I'm trying to pass a VB collection from .NET (C#) to COM Component. Please help me..
|
|
|
|
|
When I pass this pointer from Vb to C++, for some reason the value changes from when it is printed by the MsgBox in Vb, and when it is received in C++.
If I change the C++ function so that it merely asks for a long value as an argument, the same thing happens. But, if I create the Account object in C++ and pass a pointer OUT to VB, that works fine. Or, if I take the value printed by the message box, and copy that into pAcct after control has entered the GetAccount routine, everything works (the value printed from VB is valid). Its very perplexing.
Thanks for whatever advise you can give! 
VB Code
<br />
Private Declare Function GetAccount Lib "C:\...\DataAccess.dll" (ByVal ptr As Long)<br />
<br />
Private Sub Form_Load()<br />
Dim Account As clsAccount<br />
Dim ptr As Long<br />
<br />
Set Account = New clsAccount<br />
ptr = ObjPtr(Account)<br />
MsgBox Hex(ptr), vbInformation <-- Prints the following value - 0x0014F9F0<br />
GetAccount ptr<br />
Label1.Caption = "Account Name = " & CStr(Account.AccountName)<br />
End Sub<br />
C++ Code
<br />
void __stdcall GetAccount(_clsAccount* pAcct) <-- recieves the value 0x0012fadc<br />
{<br />
HRESULT hr = CoInitialize(0);
if (SUCCEEDED(hr))<br />
{<br />
_bstr_t bstr1(_T("TestInfo"));
pAcct->put_AccountName(bstr1); <-- causes access violation error <br />
CoUninitialize(); <br />
}<br />
}<br />
|
|
|
|
|
Hello rajdawg,
The problem you are facing here is most likely caused by multi-inheritance. Note well that a pointer to a class (e.g. _clsAccount) is NOT necessarily the same as a pointer to an interface that the same class implements (e.g. IclsAccount). More on this later.
I successfully re-created a crash using my own code. I created my own "GetAccount()" function and my own "ObjPtr()" function (both in C++). However, the value returned from my ObjPtr() and the value of the "pAcct" parameter were the same. I believe this has got to do with the way my "ObjPtr()" function is implemented (code is provided below).
long __stdcall ObjPtr(LPDISPATCH lpDispatch)
{
IClsAccount* pIClsAccount = NULL;
long lRet = 0;
lpDispatch -> QueryInterface(IID_IClsAccount, (void**)&pIClsAccount);
lRet = (long)pIClsAccount;
pIClsAccount -> Release();
pIClsAccount = NULL;
return lRet;
}
My crash occurred at the exact same place (i.e. when put_AccountName() was called). The reason for MY crash is due to the face that when the "GetAccount()" function is invoked, and the "pAcct" parameter is given its value, "pAcct" points to a _clsAccount object (and NOT a IclsAccount interface).
Now, as I mentioned right at the top, a _clsAccount pointer is NOT equivalent to a IclsAccount interface pointer. On some occasion, their values are indeed the same. But on other occasions, especially when your class implements several interfaces via multiple-inheritance, they are not the same. For more details, refer to "Inside COM" by Dale Rogerson (Microsoft Press).
Hence, there are two ways to overcome your problem, depending on what ObjPtr() returns :
void __stdcall GetAccount(_clsAccount* pAcct)
{
IClsAccount* pIClsAccount = NULL;
HRESULT hr = CoInitialize(0); //initializes COM library
if (SUCCEEDED(hr))
{
pAcct -> QueryInterface(IID_IClsAccount, (void**)&pIClsAccount);
_bstr_t bstr1(_T("TestInfo")); //use constructor to enter string
if (pIClsAccount)
{
pIClsAccount -> put_AccountName(bstr1);
pIClsAccount -> Release();
pIClsAccount = NULL;
}
CoUninitialize();
}
}
The above method is suitable when ObjPtr() returns a pointer to a _clsAccount class object.
This method takes the _clsAccount pointer and calls the QueryInterface() method to obtain a proper pointer to a IClsAccount interface. With a valid pointer to a IClsAccount interface, calling its put_AccountName() method goes fine.
Note that calling the QueryInterface() method from a _clsAccount pointer will succeed due to the fact that it is a common IUnknown method and will therefore be valid even from a _clsAccount pointer (see "Inside COM" for more details on this).
A second method is described below :
void __stdcall GetAccount(_clsAccount* pAcct)
{
HRESULT hr = CoInitialize(0); //initializes COM library
if (SUCCEEDED(hr))
{
_clsAccount* p_clsAccount= NULL;
_bstr_t bstr1(_T("TestInfo")); //use constructor to enter string
p_clsAccount = dynamic_cast<_clsAccount*>(pAcct);
p_clsAccount -> put_AccountName(bstr1);
CoUninitialize();
}
}
The above method is suitable if "pAcct" actually points to a IclsAccount interface.
This method takes "pAcct" (an IclsAccount interface pointer) and dynamically casts it to a pointer to a _clsAccount object. In my code, the casted pointer ("p_clsAccount") becomes a valid pointer to a _clsAccount object and with this pointer, any of class methods can be called, including methods of any interface that the class implements.
Hence alot depends on how ObjPtr() processes and returns its value.
Hope the above info will b helpful to you.
Best Regards,
Bio.
|
|
|
|
|
Hi ,
I have one issue regarding Visual studio 7 . We have a COM server which gets called from C# webservice . The setup works fine with Visual studio 6 . We compiled the code under VS 7 and reregistered all the components . There is a getmsg() loop inside the code which waits for events . When the code ran under VS 7 , the get msg loop does not work anymore . We suspect the thread is no longer the main thread and no messages for it . Does anyone know about any changes in threading from VS 6 to VS 7 .
-Kiran
|
|
|
|
|
Check project properties. Make sure the compiler is set to the proper threading type.
Kuphryn
|
|
|
|
|
Thanks for the reply
Compiler setting is Multithreaded DLL , is that what you meant ?
|
|
|
|
|
Correct.
Check ATL code. Make sure it is set for multithreading.
Kuphryn
|
|
|
|
|
I am not sure what you are doing here but you should be doing something like MsgWaitForMultipleObjects() call if you are waiting for events in a com server. Then you can get an event signal or a window message. When you get the window message you peek message. Maybe I am wrong about this but that is the way I understand it. Can you give us more information on how you are setting events? Or the code in the getmsg() loop.
|
|
|
|
|
Thanks for all the replies . I solved the problem . I changed the CoInitialize call to COINIT_APARTMENT_THREADED . Microsoft have mentioned in their help that PeekMessage will work properly only for apartments . BTW I was using MsgWaitForMultipleObjects , somehow it was peeking on the thread created from COM . Now with apartment threading it correctly Peeks on the main window thread .
|
|
|
|
|
I have an out-of-proc COM server. In one of the method of my COM server, I need Thread Id of the client application who is calling the method. Is there any way to get thread id fo client process in COM server code?
Regards.
|
|
|
|
|
Pass it as an argument.
There is more complicated way by overloading IMessageFilter::HandleIncomingCall, but I doubt you will find it appropriate/simple...
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
My Code is like:
#define UNICODE
::CoInitializeEx( NULL, COINIT_MULTITHREADED );
...
IShellLink *pShellLink;
HRESULT hr;
hr = ::CoCreateInstance( CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER, IID_IShellLink, (void**)&pShellLink );
It's very strange the code work ok on my windows 2000 and on some other windows 2000. But on someone's windows 2000 it always failed.
If i create IUnknown, it succeeded, but when query interface IShellLink it failed again. IShellLink is a macro,
so i tried use IShellLinkW or IShellLinkA, also failed.
Who knows why? Many thanks!
Ting Xu
xuting@263.net.cn
|
|
|
|
|
Maybe you didnot register on others' computer
dupengfei
|
|
|
|
|
Hello Ting Xu,
What is the return value (HRESULT) from the ::CoCreateInstance() function ?
Regards,
Bio.
|
|
|
|
|
Hello Ting Xu,
I checked out the help files under index IShellLink and noted that the IShellLink interface is implemented in Shell32.dll.
I then looked up the type library of Shell32.dll via OLEView. I noted that there are no IShellLink interface declared inside my machine's version of Shell32.dll.
There is, however, a IShellLinkDual interface as well as a IShellLinkDual2 interface in my shell32.dll. The IShellLinkDual interface looks similar to IShellLink. The "Dual" most likely signifies "dual interface". Hence it may be a newer version of IShellLink (by virtue of it being of dual interface) Please check this out.
What you can do is to use the OleView tool to view the type library of the target machine's Shell32.dll. If IShellLink is not present but the IShellLinkDual and IShellLinkDual2 interfaces are present, then you may want to use the IShellLinkDual or IShellLinkDual2 interface(s) instead :
IShellLinkDual *pShellLinkDual;
HRESULT hr;
hr = ::CoCreateInstance (CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER, IID_IShellLinkDual, (void**)&pShellLinkDual);
Hope the above helps.
Best Regards,
Bio.
|
|
|
|
|
I have an .exe application that communicates to a device through a serial port. The application is in VC++ and is dialog-based to provide a GUI for interfacing to the device. I also needed a COM interface to allow access to the device to be scripted. I wanted to allow multiple scripts to access the device and allow the GUI dialog to be opened or closed at any time while the scripts are running. The problem, unless I'm way off track, is that I need there to be only one instance of the server so that it can route all traffic through the same serial port.
After I initially created the application containing an automation class, the problem was that running a .vbs script would create one instance of the server and running the .exe created a second instance of the server.
Then I found that if I moved the COleTemplateServer::RegisterAll() call in front of the "if (RunEmbedded() || RunAutomated())" line that running a .vbs script would attach to the already running instance of the server, but not the other way around. If I run a script first and then execute the .exe a second instance of the server is started and it cannot talk to the serial port because the first instance has control.
Next I used the SingleInstanceApp class I found on this website and with it I was able to detect that I already had an instance of the server running when launching the .exe and it sends a registered message to the first instance and then terminates. The first instance receives the message and launches the GUI dialog if it is not already active. So with this change I now am guaranteed to only have one instance of the server running at a time but it left me with one problem.
Once I launch the dialog I cannot close it because it terminates the server and basically pulls the rug out from under any script clients that are using the server. I tried intercepting the WM_QUIT message using ProcessMessageFilter and that does work if I run a script first, launch the .exe, and then close the .exe. But if I start the .exe first and then start running any scripts, the server is terminated when I close the dialog.
I know this was a long message but I've been banging my head against the wall to try to solve this and any help would be greatly appreciated.
Gil Jones
|
|
|
|
|
But if I start the .exe first and then start running any scripts, the server is terminated when I close the dialog.
As I undertsand it's MFC app. If so, as I recall:
you may consider looking into the call to AfxOleSetUserCtrl(FALSE) in the sequence when you first start .exe and later get Automation CreateInstance...
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
