|
Scenario: Interrop:
(a).NET C# library packaged into a COM server
(b) COM server used in a C++ WIN32 console app that supports ATL.
Hi, I have wrapped up a simple C# managed class library with:
1. RegAsm.exe
2. gacutil - to install the signed assembly into GAC.
I successfully installed the assembly into GAC and created the tlb file with RegAsm. But I'm having trouble using it from my WIN32 console app.
The C# class is like this:
namespace ManagedCLib
{
public __gc class CSomeObj
{
public:
int MultiplyThis(int num1, int num2) { return num1*num2; }
public:
CSomeObj() { m_nID=0; }
__property int get_nID()
{
return m_nID;
}
__property void set_nID(int value)
{
m_nID=value;
}
protected:
int m_nID;
};
}
Very simple right? After the C# class lib is compiled/installed into GAC/tlb created, I copied the tlb file to the client WIN32 app's directory. My simple client code looks like this:
#include "stdafx.h"
#import "managedclib.tlb" //Type library referenced (It's now in client's directory)
int _tmain(int argc, _TCHAR* argv[])
{
CoInitialize(NULL); //Initialize COM library.
USES_CONVERSION;
ManagedCLib::_CSomeObjPtr obj( __uuidof(ManagedCLib::_CSomeObjPtr)); //CRASH HERE! Before invoking any method??
return 0;
}
The application code crashed - just a. I presume a .NET class lib packaged into a COM server with RegAsm.exe is a "in-process server". But I have no idea how to debug this, any direction? Thanks.
norm
|
|
|
|
|
Try CoCreateIntance, check HRESULT...
Shouldn't you use?:
ManagedCLib::_CSomeObjPtr obj;
obj = obj.CreateInstance(__uuidof(ManagedCLib::_CSomeObjPtr));
...
Regards
"...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
|
|
|
|
|
if(!::CreateProcess(NULL, "F:\\software\\develop\\sometool.exe",NULL, NULL, false, 0, NULL, NULL, &si, &pi)){
AfxMessageBox(ShowError("CreateProcess"));
}
if(::WaitForInputIdle(pi.hProcess, INFINITE) == 0){
::GetGUIThreadInfo(pi.dwThreadId, &gui);
}
but it doesn't work, the parameter gui's content is 0 except the cbSize member
why?
|
|
|
|
|
|
could somebody please suggest a book for learning how the windows os stores resources from PE files in memory and how they relate to the opcode when the execution process starts?
I'm sure the resources aren't listed as some kind of data segment and I'm confused about how they fit into the execution of opcode when the opcode is loaded into memory from the execution start on a PE file.
I DO NOT want a book on PE file format, because I already have one. I really need something that explains the relationship between PE resources and the actual opcode of the PE file when the opcode is loaded into memory and the start address is loaded into the register and the whole process starts.
This relates to VC++ because I intend to use this information in a VC++6 project, thank you.
|
|
|
|
|
|
Hi,
I’m new to MFC and need some help on it. Here are the topics on which I need help:
1. How to add different colors and images to the individual elements in the Tree Control? Code snippets would be great.
2. How to make right-click pop-up menu and how to write handlers for menu selection? Any pointer/tutorial/code would be awesome.
3. How to make my own dialog menu and write handlers for the menu selection? Tutorial or, code would be appreciated.
Thanks in advance MFC-Gurus,
Binayak
|
|
|
|
|
|
I use com to work with excel form c;
With the aid of the classwizard i've generatad a class MySeriescollection
//doing something in excel
MySeriesCollection mySeriesCollectionObj;
IDispatchPtr seriesCollectionDispatchPtr = pXL->ActiveChart->SeriesCollection();
seriesCollectionDispatchPtr.AddRef();
mySeriesCollectionObj.AttachDispatch(seriesCollectionDispatchPtr);
//working with mySeriesCollectionObj
mySeriesCollectionObj.DetachDispatch();
seriesCollectionDispatchPtr.Release();
My Problem is that after working with excel there is still a process in the taskmanager.
The reason is seriesCollectionDispatchPtr.AddRef();
If I work without the Class MySeriesCollection it works an the process is killed at the end.
seemed to be that mySeriesCollectionObj.DetachDispatch(); ist not enough
What have I to do that the process is killed in the end .There musst be some rest in the memory that forces the process to keep alive and i know that it is seriesCollectionDispatchPtr.AddRef(); that causes the problem
Any Ideas?
Thx Heiko
//mySeriesCollection Class
LPDISPATCH MySeriesCollection::GetApplication()
{
LPDISPATCH result;
InvokeHelper(0x94, DISPATCH_PROPERTYGET, VT_DISPATCH, (void*)&result, NULL);
return result;
}
long MySeriesCollection::GetCreator()
{
long result;
InvokeHelper(0x95, DISPATCH_PROPERTYGET, VT_I4, (void*)&result, NULL);
return result;
}
LPDISPATCH MySeriesCollection::GetParent()
{
LPDISPATCH result;
InvokeHelper(0x96, DISPATCH_PROPERTYGET, VT_DISPATCH, (void*)&result, NULL);
return result;
}
LPDISPATCH MySeriesCollection::Add(const VARIANT& Source, long Rowcol, const VARIANT& SeriesLabels, const VARIANT& CategoryLabels, const VARIANT& Replace)
{
LPDISPATCH result;
static BYTE parms[] =
VTS_VARIANT VTS_I4 VTS_VARIANT VTS_VARIANT VTS_VARIANT;
InvokeHelper(0xb5, DISPATCH_METHOD, VT_DISPATCH, (void*)&result, parms,
&Source, Rowcol, &SeriesLabels, &CategoryLabels, &Replace);
return result;
}
long MySeriesCollection::GetCount()
{
long result;
InvokeHelper(0x76, DISPATCH_PROPERTYGET, VT_I4, (void*)&result, NULL);
return result;
}
VARIANT MySeriesCollection::Extend(const VARIANT& Source, const VARIANT& Rowcol, const VARIANT& CategoryLabels)
{
VARIANT result;
static BYTE parms[] =
VTS_VARIANT VTS_VARIANT VTS_VARIANT;
InvokeHelper(0xe3, DISPATCH_METHOD, VT_VARIANT, (void*)&result, parms,
&Source, &Rowcol, &CategoryLabels);
return result;
}
LPDISPATCH MySeriesCollection::Item(const VARIANT& Index)
{
LPDISPATCH result;
static BYTE parms[] =
VTS_VARIANT;
InvokeHelper(0xaa, DISPATCH_METHOD, VT_DISPATCH, (void*)&result, parms,
&Index);
return result;
}
LPUNKNOWN MySeriesCollection::_NewEnum()
{
LPUNKNOWN result;
InvokeHelper(0xfffffffc, DISPATCH_METHOD, VT_UNKNOWN, (void*)&result, NULL);
return result;
}
VARIANT MySeriesCollection::Paste(long Rowcol, const VARIANT& SeriesLabels, const VARIANT& CategoryLabels, const VARIANT& Replace, const VARIANT& NewSeries)
{
VARIANT result;
static BYTE parms[] =
VTS_I4 VTS_VARIANT VTS_VARIANT VTS_VARIANT VTS_VARIANT;
InvokeHelper(0xd3, DISPATCH_METHOD, VT_VARIANT, (void*)&result, parms,
Rowcol, &SeriesLabels, &CategoryLabels, &Replace, &NewSeries);
return result;
}
LPDISPATCH MySeriesCollection::NewSeries()
{
LPDISPATCH result;
InvokeHelper(0x45d, DISPATCH_METHOD, VT_DISPATCH, (void*)&result, NULL);
return result;
}
|
|
|
|
|
If you are correctly releasing your interfaces then the application object UserControl flag is probably the cause.
See Q238987
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q238/9/87.asp&NoWebContent=1
Q192348 may be of interest as well
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/KB/Articles/Q192/3/48.asp&NoWebContent=1
SYMPTOMS
The Office application you are automating continues to reside in memory after your Visual C++ program finishes executing.
CAUSE
Most likely the application is still in memory because you have forgotten to release an acquired interface.
RESOLUTION
Here are some general suggestions and things to looks for when trying to determine the cause of the problem:
If you're using #import, it is very likely you could be running into one of the reference-counting bugs associated with it. Often times the bugs can be worked around, but usually it is preferred to use one of the other Automation methods. #import doesn't work very well with the Office applications because its type libraries and use are fairly complex. Also, such reference counting problems are hard to track down because a lot of the interface-level COM calls are behind-the-scenes when using #import.
Check to see if you are calling any methods that return an IDispatch * (LPDISPATCH), such as Open or New, and ignoring the return value. If you are, then you are abandoning this returned interface and will need to change your code so that you release it when no longer needed.
Gradually comment out sections of your code until the problem disappears, then add it back judiciously to track down where the problem starts.
Note that some applications will stay running if the user has "touched" the application. If this occurs while you are automating, then the application will probably stay running afterwards. The Office applications have a "UserControl" property on the Application object that you can read/write to change this behavior.
Also, some applications will decide to stay running if enough user-interface "action" has occurred. If you intend for the application to exit, then call its Quit() method on the Application object. Word will shutdown regardless of its reference count when Quit is called. This isn't expected COM behavior. Excel, however, will properly just hide itself but stay running until all outstanding interfaces are released. In general, you should release all outstanding references, and only call Quit() if you intend the application to quit.
|
|
|
|
|
Many thanks for your help
I doesn't expected somebody would answer
Unfortuneately I couldn't find the failure
It is definitv this line of code that causes the problem seriesCollectionDispatchPtr.AddRef();
I don't understand why my seriesCollectionDispatchPtr.Release(); doesn't decrements the pointer If it would do so I think the memory would be freed
Now i've killed the process with TerminateProcess. Do you think this will cause trouble?
|
|
|
|
|
Without thinking in through too logically have you tried.
while ( seriesCollectionDispatchPtr.Release() > 0 ) { /*decrementing ref*/ };
|
|
|
|
|
Yes
i wanted to try the same you suggest
Unfortuneately the Release-method of this interface returns void
|
|
|
|
|
Is there a way to force "cout" to show what's in its buffer?
Debugger shows there's data in the array, and the program dump shows there's data in the array, but "cout" will NOT show it!!!
Thanks!
William
Fortes in fide et opere!
|
|
|
|
|
Why not just overload the << operator and dump the results out?
-Nick Parker
|
|
|
|
|
Thanks for replying.
I did exactly what you suggested which is how I know "cout" has the correct set of data in its buffer, but when I do:
cout<<" ==> " <<parr <<endl;
"cout"="" shows="" everything="" <b="">EXCEPT the first string in the array. All the other strings got shown.
William
Fortes in fide et opere!
|
|
|
|
|
In the "for" statement, one of the conditions was testing for equality when it should have been testing for "NOT EQUAL". 
As soon as the correction was made, everything returned to normal.
Perhaps there isn't, but it sure would have been valuable to know if there was a way to force "cout" to print its buffer.
William
Fortes in fide et opere!
|
|
|
|
|
I do not know whether I understand your problem, but - if I correctly understand - you can use cout << flush to force everything to be displayed on your screen (or the standard output). This piece of code may be needed when using different libraries, e.g. using both cout and getch(). For example:
cout << "Press any key to continue...";
getch();
will give no output and will wait for a key to be pressed. Meanwhile,
cout << "Press any key to continue..." << flush;
getch();
will give the desired output. Notice that endl and cin also call flush, so you don't usually need to call it explicitly.
Hope this helps.
<marquee>Hosam Aly Mahmoud
|
|
|
|
|
redirect cout to another stream that you control...
Jonathan de Halleux.
|
|
|
|
|
In my main rich edit view, I want to add a gutter to display line numbers. I am doing an MDI MFC app and have NOT found any way to do this. If anyone knows of any solutions to draw line numbers or add gutters to rich edit view/control, please reply! Thanks!
|
|
|
|
|
Hi Gurus,
i woul like help here! is there a way i can call an SDI from another SDI just like i can call a Dialog from an SDI, if any one has an answer, then am quite gratefull for your Advise.
GBU.
Sharing is a gift of nature.
|
|
|
|
|
Hi,
I am using the code provided by Chris and it works like a champ, but I would like to know how I can minimize the dialog to systray whenever someone presses the close ("X") button?
Thanks in advance! 
Regards,
Varun Shoor
|
|
|
|
|
So you already have the code to minimize to systray?
Override OnSysCommand or WM_SYSCOMMAND and handle SC_CLOSE, put your systray-code there 
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
you get a message, that your dlg is closing.
WM_CLOSE or WM_QUIT 
you can catch the message, and make your dialog go to systray
|
|
|
|
|
This is not the correct way to catch the [x]-button click 
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
