|
Okay, so I changed to:
CComVariant Values = new CComVariant(m_psaVal);
But I still get the same error.
It sounded like the solution though.
|
|
|
|
|
Hello Hampus@foi,
I see 2 problems in your code :
1. The 2nd parameter to FireEvent() function is EVENT_PARAM(VTS_VARIANT). This means that the 3rd parameter should be a pointer to "Values".
As a further suggestion, make the "Values" parameter to FireOnNewBuffer() a VARIANT reference (i.e. VARIANT&) instead of a straight VARIANT type. Using a reference saves space and improves performance. Using a VARIANT type would entail copying of the original "Values" from MycFunction() to the stack of FireOnNewBuffer().
Hence a better definition for FireOnNewBuffer() is as follows :
void FireOnNewBuffer(const VARIANT FAR& Values)
{
FireEvent(eventidOnNewBuffer,EVENT_PARAM(VTS_VARIANT), &Values);
}
2. The use of CComVariant for a SAFEARRAY is not appropriate :
CComVariant Values(m_psaVal);
This is because there are no CComVariant constructors that take a SAFEARRAY*.
Instead, I suggest using a VARIANT type :
//CComVariant Values(m_psaVal); // <-- comment out.
VARIANT Values;
VariantInit(&Values);
VariantClear(&Values);
V_VT(&Values) = VT_ARRAY | VT_UI1;
V_ARRAY(&Values) = m_psaVal;
FireOnNewBuffer(Values);
Hope the above helps.
- Bio.
|
|
|
|
|
Excellent, it works perfectly!
You are the greatest, thank you very much!
|
|
|
|
|
Most welcome, Hampus@foi.
|
|
|
|
|
I have Automation object implemented as a local server (.exe). Client creates it through CreateDispatch(...). Default behavior for Automation, when client is closing, is to destroy all COM stuff in OleUninitialize(). As a default - it's ok, but I'm trying to run my server disconnected from the client as it has to perform very lengthy operations.
If I set dispatch's m_bAutoRelease to FALSE, it keeps my dispatch in the runningobject table, nevertheless server's MainFrame window gets WM_DESTROY and WN_NCDESTROY and server gets closed.
Attempt to set (in server) AfxOleUserContorl(TRUE), while calling server very first time, seems to have no effect on server default distruction.
Is there any way to change the default behavior and avoid local server destruction (closing)  ?
|
|
|
|
|
The server COM is running in the client threads, so it gots terminated with it. :
For lengthly and repeated threads it is use to write services. Or create a own COM-Thread (App-Server) to which clients can connect (via RPC).
I hope it will help.
Greetings from Germany
|
|
|
|
|
Terminology on COM-Automation is NFG.
Yes, I know that if I'm calling an InProcServer (put it simply DLL) it will run in the client appartment using its main thread and will be terminated upon Client closing. All fine with this logic, but I'm calling a LocalServer (put it simply an .exe program), so calls are marshaled to my executable. Executable has its own tread(s) (process). All I want - to be in control of closing my running Executable, which is a separate process (acording to docs).
Thx for reply.
Greetings from Canada.
|
|
|
|
|
Hi All, I recently developed a shared COM Addin using VB.Net and Outlook 2003. It works great on local machine but when I install it on Terminal server it doesn't work.
My Addin get installed on Windows 2003 Terminal server with the initial Loadbehavior = 2Hex value under the HKEY_LOCAL_MACHINE in registry. It starts working when I change it to 3Hex. But as soon as another user logs in on termail server and starts outlook, the loadbehavior values becomes 2Hex again and my Addin stops working for every user.
Any idea why registry is being changed by every user session. I will appreciate your response.
Thanks
|
|
|
|
|
hi to all,
i have created a com object with c# and my output project is *.dll,
now i nead to export it to .lib file, how to do this work?
so thanks
bye
|
|
|
|
|
Where can I find the exact steps required to do this? I don't want to trust a new dll to properly unregister COM classes registered by a previous version of that dll, so before calling DllRegister whatever, I want to make sure my registry is cleaned of all traces of a component.
|
|
|
|
|
Have a look at [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
the standard way is to call as admin "regsvr32 /u *dll"
But it depends on the implementation if it does every thing right.
Or install the dll on a fresh system and compare registry before and after. But it can also be, that the dll is writing something at runtime. 
A proper COM Server uses the same CLSIDs while it is compatible and use others if there is no compatibility.
Greetings from Germany
|
|
|
|
|
hi,
i had to upgrade one of our fileupload COMponent written in VB6 which was used in classic asp to a .net component. im able to write up the component but only problem is when passing he request to the .net component it is passed as ASPTypeLibrary.Request but i want it as System.Web.HttpRequest... is there anyway i could achive it.
and also the previous upload component fails when files are larger than 1 mb in our production environment, and works well in our qa and development environments. the <httpruntime maxrequestlength="10000" executiontimeout="300"> settings are givent correctly . but it fails. any idea about this.??
im deaf to the word no
|
|
|
|
|
I'm trying to implement registration free COM from a 'developer as a user" point of view, i.e. I would like to skip the requirement that the COM server be registered on the developer's (my) machine in order to produce the manifest files. All the guides on registration free COM seem to require the COM server initially being registered.
Surely there are some tools and or API's that would allow the dynamic creation of a manifest file for this purpose. Anyone?
|
|
|
|
|
Can you elaborate on the following:
Brady Kelly wrote: be registered on the developer's (my) machine in order to produce the manifest file
What's the deal with "the manifest file"?
Steve
|
|
|
|
|
The manifest file stores the information that would normally come from the registry for a registered COM server, e.g. the type lib ID, CLSID, etc.
|
|
|
|
|
You read some fine manual of COM. The registration is necessary to get them work. 
The CLSID got an entry in the registry so the COM-Client finds the dll and can instanciate COM-servers.
If you dont want this, you can dynamically load dlls and call their functions. 
Greetings from Germany
|
|
|
|
|
KarstenK wrote: You read some fine manual of COM.
Maybe you should also read some manuals[^]. Then you would know that from Windows XP onwards, registration-free COM is possible using application and assembly manifest files instead of registry entries to locate the codebase.
|
|
|
|
|
Brady Kelly wrote: Then you would know that from Windows XP onwards, registration-free COM is possible using application and assembly manifest files instead of registry entries to locate the codebase.
Registration-free COM was available even before, using file monikers.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
I've been googling to find exactly what you're looking for.
check out the manifest tool: \Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe
sample usage to create a manifest from an rgs and tlb:-
mt.exe -rgs:MSClus.rgs -tlb:MSClus.tlb -dll:foo.dll -replacements:replacements.manifest -identity:"type=win32, name=Microsoft.Tools.SampleAssembly, version=6.0.0.0, processorArchitecture=x86, publicKeyToken=6595b64144ccf1df" -out:rgstlb.manifest
|
|
|
|
|
Cool, thanks. Watch out for an upcoming article on using the Activation Context API to even trim off having to use manifests.
|
|
|
|
|
Guys,
I quickly rigged up a .NET Windows UserControl with few text boxes and methods based on an Interface. I have added a simple interface. When the object is loaded in IE, it shows as a missing image. Ihave gone through the ie settings a to make sure the security for actives is set appropriately. The dll was compiled with com enabled and is also strong named.
Framework: 2.0
IE: 7.0
Can some one give any advise on how I may solve this issue.
Thanks,
Shrini
|
|
|
|
|
It looks like the IE is not finding the Class to create an instance. is it correctly registered (with regsvr32 and the CLSID in the registry)?
You can debug the controls, via starting the IE in the debugger and open a html page with it 
Greetings from Germany
|
|
|
|
|
Hi All,
It was my understanding that when an outbound call is made from an STA, the subsequent running of the message loop while waiting for that call to return would only process UI related messages (such as WM_PAINT) thus allowing the UI to remain responsive. However, I'm seeing a situation where it seems that additional messages (perhaps all messages) are being processed during this time. In my situation, multiple external threads are calling into the same method in the STA. During the execution of this method, an outbound call is made, thus I wind up with several concurrent executions in the same code path - something that was not expected. What messages are processed by an STA waiting on an outbound call?
I've read some about the IMessageFilter interface and it seems that this provides the capability to do what I'm talking about. Does its existence indicate that by default, no filtering occurs?
Thanks in advance for your help. Also, any references you could point me to would be greatly appreciated.
|
|
|
|
|
Synchronization of COM method calls within an STA is done via window messages. That's why an STA has to pump messages. The exact messages used for that purpose are an implementation detail. But even if you did know which messages they were, if you purposely didn't process them, you would cause a deadlock when an incoming method call happened - the caller is waiting for the method call to return, but you're intentionally not letting the method call happen.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
