This is really interesting, and it sounds like an enormous amount of work.
About a year ago, I was getting familiar with MIDI (a computer music format), and there was a company that was promoting a DirectX COM interface standard for creating what is known as a software synthesizer (which could process MIDI messages into sound). This component would be loaded into an application that would stream MIDI messages (which comprised a musical composition) to the synthesizer component, the COM interface would process the MIDI format and return a stream of what was essentially a continuous stream of WAVE format digital signals, which the application would then send to its own audio driver. Pretty complicated stuff. Anyway, the company (Cakewalk) that develops the music software, offers developers an SDK package (including source code for both minmal server and compatible client, and lots of html documentation) demonstrating the utility of the server component and the interface that the COM In-Process server must present to the Executable, and all the associated data structures, interfaces, callbacks, and related mechanisms required to make the whole thing work.
Admittedly, it is probably more complicated that what you are suggesting. But, the point is that the COM structure must be provided and thoroughly tested, and the documentation must be clear to the client developer, before they can even begin to design a component that will interface with your server correctly.
In the above mentioned example, I had to study the source code for several weeks before I completely understood how it worked, and especially, how the server-client connections were implemented. What you realize is that, the more complex the code model is, the more difficult it is to get it to work.
I read your other post in the C++/MFC forum. Pallini is correct (always is, in fact), you must start with MIDL.
You might also find this online book useful: Inside COM++[^]. It's quite similar to Don Box's, "Essential COM".
One way would be to render it into a bitmap created using the CreateDIBSection[^] function. You could also try looking at the GetDIBits[^] function. With both of these you use the handle returned by the get_Handle method.
But this statement makes the control's container crash without any message!
If I replace my description string with some harcoded message, it works just fine. But whenever I rely somehow on the e.Description, bang, it crashs.
I assumed it could already be freed the time it would be read on the container side, so in a further step I tried to copy the description in a new allocated variable, to save it somewhere within the control instead of locally within the catch-block, etc. But nothing works.
What are the reasons why I cannot "forward" this errror description? It can be logged correctly, but I have no chance to bring it on the containers side.
Thank god it was not my fault, but the container that embedded my control cannot handle long error descriptions.
The common ActiveX Testcontainer could receive those COM error message without any problem, but the application that instantiated my control killed itself whenever it got long messages. Seems like they are using a small buffer and try to copy the long message into a small character array or whatever.
As workaround I simply truncate my error messages. (Ok, over 1000 characters error description is perhaps really very very long )
But is there are maximum size for error descriptions defined? I could not find any restriction regarding the length... and TstCon32 can handle long messages. Hm
You give only little information about the .net control... there are several possible ways, but most are simply dirty hacks (e.g. using SetParent on the .NET control's window handle and embedding it into your c++ ATL window. Ah, don't do this!)
In general I would say that's no COM question, but anyway:
Best way (in my opinion) would be to build a C++/CLI wrapper around your control. You could write a C++ control and create an instance of your .NET control on top of it. Mixed-mode at its best!
If you're using .NET Framework 3.5 or previous for your applications, you're going to be forced to break out Reflection[^] to either manually deserialize the COM object into your custom types, or to just manually access the members themselves. If you're using .NET Framework 4, you can use C#'s new dynamic keyword to do the same thing with little excess code.
Adam Maras | Software Developer Microsoft Certified Professional Developer
yea this is in 3.5, I can go the Reflection route and see where that leads me. I've been trying to Marshal it, then read about needing an interface but can't for the life of me think of why or how I would implement an interface in this design type. Just doesn't fit with what im wanting to do.
But thanks for the time and reply. I'll do some tests and see if it works using that.
We have implemented a Method type of WMI Provider.
1) It is a coupled provider and its loading / unloading is handled by WMI. Specifically it is loaded in WMIPrvSE.
2) UnLoadTimeout is set to NULL and Pure property has been set to TRUE
3) The WMI provider methods have been declared static in the MOF file also.
In this context, we have a requirement where the client needs to call one method on the WMI provider and when we call the next method, it needs to "remember its state". The client application holds the connection to the object and tries to call the next method. However we are noticing that the provider is being unloaded and the next method call happens on a different object itself.
Please let us know your suggestions on resolving this problem. Can we achieve this functionality with method type of provider at all??
I am developing an application to play mp3 files using directshow .I want to show visualization like windows media player .But I am not getting how do i this . Is there any filter or any technique to show visualization in custom mp3 player.
I have an issue where the majority of our applications that we have built are ms access 2003 based applications however several of the applications have went thru MS Office 2007. When this happened the MODI active x control changed from version 11 to version 12. Now the applications all crash on machines where ms office 2007 is not installed on. Is there any way of installing the active x component with the application on the 2003 machines with out reinstalling ms office 2007?
I get an error 438 that the object does not allow for the property if the machine has only ms office 2003 installed. But when ms office 2007 is installed (Only the document image (MDI) Application) it will work just fine). What can I do to resolve this issue for us and our customers who do not have ms office 2007. I have tried removing all references and controls from the application, then putting the references back on a machine that has only 2003 installed on it but the problem stays intact. Some how it is still referencing the MODI Version 12 ocx active x control not the v11.
FROM: "Compatibility Flags"=dword:00000400
TO: "Compatibility Flags"=dword:00000000
After this change everything works fine, but when I restart the computer the security update is installed again.
Is there any other solution to get this component working again, than changing the registry?
Or is there a registry value to change which suppresses the Micorosoft Update to run again?
Any other ideas?
I create Toolbar button using TBBUTTON. To set tootip i set SendMessage(m_hWnd, TB_SETMAXTEXTROWS, 0, 0L), by doing this iString member of TBBUTTON is set as ToolTip, but i want both, ToolTip and Caption to Toolbar button.So how can i set this.
I refer http://msdn.microsoft.com/en-us/library/bb760446(VS.85).aspx#Displaying_Tooltips_for_Buttons link.
VariantClear( p );
VariantInit( p );
p->vt = VT_BSTR | VT_BYREF;
BSTR *pBSTR = new BSTR;
*pBSTR = SysAllocString( L"abc" );
p->pbstrVal = pBSTR;
And my client in VB is like this:
For i = 1 To 1000
Dim myInt As Integer
myInt = 3
ret = client.CallService(myInt)
As far as I know the COM engine is creating a VARIANT from my integer (which is received as VT_BYREF | VT_I2), and I change it to VT_BSTR.
The VB loop causes a huge memory leak.
Am I doing something wrong ? How the COM engine handles the new VARIANT/BSTR deallocation ?
It was my first guess, but I don't think so...each time I receive a call (from the loop) I receive the same integer VT_BYREF | VT_I2 (which is deallocated by VariantClear).
It seems that this BSTR is lost between calls, causing the leak (obviously myInt is an integer and can't reflect changes).