|
you might need to write a BHO. Its add-in to IE.
Look for BHO on CP.You will get help to add one.
|
|
|
|
|
Hello,
I am implementing a Shell extension and it create a virtual folder to map to d:\\temp,
I create a thread use ReadDirectoryChange to watch d:\\temp have any write action,
the thread is in COM dll shell extension's EnumObject function(the create's place maybe not the root cause),
and want when user close the explorer, I'll tell the thread to exit(means no more need to watch any write action in virtual folder).
Right now the only place I can thourht is when call DllMain's process_detach,
I have following scenario,
1. when I use SetEvent(hStopEvent) to set a global event in DllMain's process_detach tell thread to stop, the thread's waitforsingleobject(hStopEvent, Infinite) to wait the global event didn't wait the event signal, it still block in waitforsingleobject(hStopEvent, Infinite),
But when I move the SetEvent(hStopEvent) to other place, not in Dllmain's process_detach, it works fine, the thread will wait htat event succes anf exit himself.
2. I can't solve the question one, Because the only place I know can stop thread is DllMain's process_detach, so I decide set a global boolean bStopThread, the thread will keep check that boolean to decide stop thread or not, and set bStopThread to TRUE in DLLMAIN's process_detach,
But after I set the bollean to TRUE, it seems thread didn't run to check bollean point, then the DLL is exit, so I don't know thread is end or not, I thought it didn't end, because I use debug mode to trace, thread didn't run to check bollean point, but the DLL already exit.
Question is,
1. In scenario two, the thread is end or not? it seems thread didn't end? but I can delete that dll afte dll exit, so it means the thread have already end?
2. how to slove Scenario one, to let thread can wait a global event and set event in DLLmains process_detach?
Thanks for your help~!!
|
|
|
|
|
I already implement ReadDirectoryChangesW in Asynchronus mode, and add OVERLAPPED event.
EX:
while(TRUE)
{
ReadDirectoryChangesW(...)
HANDLE hHandle[2];
hHandle[0] = stop thread global event;
hHandle[1] = OVERLAPPED event
ret = waitformultipleobject(2, hHandle, FALSE, INFINITE);
case(ret)
......
}
the OVERLAPPED event works fine, I can always read directory change's return result,
My question is when I use setevent to set stop global event in DLLMain's process_detach, ret = waitformultipleobject(2, hHandle, FALSE, INFINITE); didn't return~!!
but if I move setevent(stop global event) to other function,
ex:
1. in my function CreateThread() creat ReadDirectoryChange thread.
2. for test Sleep(5000) in function CreateThread();
3. SetEvent(stop thread global event).
The ret = waitformultipleobject(2, hHandle, FALSE, INFINITE); will return successfully, and do correspond stop thread action.
Why I use SetEvent(stop thread global event) in DLLMain's process_detach didn't work?
|
|
|
|
|
I was wondering if someone could give me a hint on how to access the objects in the IHTMLElementCollection returned from get_applets(). I can get to the IHTMLElement and see the innerHTML - that indeed I have the correct objects. I am was hoping for something similar to images where you get the object as a IHMTLImgElement, that gives you specific functionality based around images, except in this case for the embedded objects.
I have been tasked with extracting various parts of webpages, the missing functionality is retrieving where media players(embedded) are getting content and what flash players are using for content. I expected the embeded objects to come in from the get_embedded() call, but look at the IE DOM, they are indeed placed under the applet branch. I can get the innerHTML, and parse it myself, but if there is some object like IHTMLAppletElement(which I don't think exists from the IDL - and MS docs are vague about, other than images, links and anchors) that gives me specific funcationality, would be great. I don't want to parse the innerHTML unless it's my last resort. That will leave me in the relative vs absolute path quagmire for the media paths.
Thanks in Advance.
|
|
|
|
|
I have COM object written in C# that exposes connection points and deployed as out of process server.
I wrote VB6 application that supplies handler for the events fired by this COM object.
To do that I added reference in my VB project to type library generated for C# COM.
Next I used WithEvents statement in my VB code to declare variable of the events firing type exported from the COM.
The application works fine. I can consume the events from the C# COM in my VB6 code.
Problem arises when I stop my VB application.
The delegate that implements the event in C# remains assigned and exception is thrown when attempt is made to call it.
When you implement Event Sink say in C++ you use Advise – Unadvise paradigm to assign and clean up your handlers.
What you supposed to do in VB6?
Any help will be appreciated.
|
|
|
|
|
Please don't cross post.
---
b { font-weight: normal; }
|
|
|
|
|
I would like to derive multiple interfaces from the same base interface.
In the IDL file I have the following:
<br />
interface IBase : IUnknown<br />
{<br />
HRESULT BaseFunc ();<br />
};<br />
<br />
interface IDerived1 : IBase<br />
{<br />
HRESULT Derived1Func ();<br />
};<br />
<br />
interface IDerived2 : IBase<br />
{<br />
HRESULT Derived2Func ();<br />
};<br />
This actually works, but I guess that's the wrong approach, because if I now implement the interfaces in C++ that doesn't work well.
<br />
class CBase : public IBase ...<br />
class CDerived1 : public IDerived1 ...<br />
class CDerived2 : public IDerived2 ...<br />
CDerived1 and CDerived2 would then have to re-implement the methods of CBase. This could be avoided by making CBase a template, but is this actually how it should been done?
Or is this the correct way?
class CDerived1 : public CBase, public IDerived1<br />
{<br />
};
The IBase interface should be exposed to the clients of the IDerived interfaces and the implementation is the same for all derived interfaces.
I haven't found any examples where multiple interfaces are derived from a base interface, it would be great to see same sample code.
Thanks
|
|
|
|
|
If CBase implements IBase (which includes the IUnknown methods) then you second example is fine: the IUnknown and IBase method implementations are inherited from CBase and the implementation of the extra methods introduced by IDerived1 are implemented by CDerived1.
A more typical solution is that CBase just implements IBase not including the IUnknown methods and CDerived1 would implements IUnknown and the extra methods introduced by IDerived1. This would also look something like your second example.
Steve
|
|
|
|
|
Hi Steve, thanks for your reply.
IBase should never be instantiated, only the derived interfaces, so IBase shouldn't implement the IUnknown methods, right?
Is this good practice or should I use COM aggregation? I would like to avoid aggregation because it doesn't make sense to instanciate 2 objects and then delegating IUnknown.
So this would be the prefered way?
class CBase : public IBase<br />
{<br />
BaseFunc ();<br />
};<br />
<br />
<br />
class CDerived : public CBase, public IDerived<br />
{<br />
AddRef ();<br />
Release ();<br />
...<br />
<br />
DerivedFunc ();<br />
};
|
|
|
|
|
If you're talking about COM aggregation then you must be aware that you can only use it on COM objects which support it - I don't think it will help you here unless you’ve already got an existing COM object which you wish to use in building another COM object which exposes some or all or its functionality.
I see no reason for the CBase class at all unless you plan on reusing the IBase implementation in many objects.
Typically the most derived class implements the IUnknown methods although other scenarios are possible.
I'd use ATL.
Steve
|
|
|
|
|
All,
I am working on ATL COM DLL and I am writing a DLL which exposes few interfaces to the application. These interfces can be called either from the VBScript or C++ routine. Any rules which i need to follow especially for having a parameter[[IN], [OUT]. As every one knows that VBScript has data type limitations and we can't pass all the parameters as like in normal. For example the IN and OUT parameter will be used to send and receive values from the interfce and should always be having a VARIANT* data type.
For example:
1. STDMETHODIMP CXX::FUNC_XX( BYTE bnl,BYTE bCurrCl,VARIANT* vSData,BOOL boFlag, SHORT *pRetVal)
2. STDMETHODIMP CXXX::FUNC1_XXX(VARIANT* vReconfig,SHORT *pRetVal)
Please let me know if any one is having suggestions or sample ATL COM DLL which can be called from VBScript.
Thanks,
AKS
|
|
|
|
|
To call a COM interface from VBScript you need a dual interface with IDispatch.
|
|
|
|
|
Hi,
Thanks for answer. But i am mainly interested in knowing what are all the basic rules (such as supported data type of parameters and etc) which i need to follow when i want to write a com dll which can be used from the VBScript especially.
Thanks,
Siva
|
|
|
|
|
Whenever possible I use setters for strings (BSTRs) rather than getters, but sometimes this is not possible.
The advantage of a setter is that I only have to guarantee the lifetime of the string during the call of a method, and since the calls are synchronous the string can be on the stack, on the heap or in the resources and the other component doesn't have to care about it.
But how about getters, GetName for example. Should the caller pass a buffer? Should the callee make a copy of the string and offer a method to free the string? Or should the caller assume that the string will not be deleted during the execution of its own method and just not save the pointer for later use?
I would like to use a consistent way that works across different languages.
|
|
|
|
|
You should create the string with SysAllocString. The caller should free the string when it's finished with it using SysFreeString.
|
|
|
|
|
I guess you are right and that is the only way it should been done. I've just seen to many other ways how strings are handled.
Often C++ memory management is beeing used which is really bad because it assumes that the caller uses the same memory management as the callee.
During marshalling the .NET runtime calls SysFreeString for returned BSTRs, so anything else than SysAllocString doesn't seem to work.
|
|
|
|
|
The defined way of manipulating BSTRs is to use the SysXxxString methods. Anything else is just plain wrong and needs to be fixed.
OK, if you're copying a BSTR parameter into a member variable, you can use any allocator you like for your member variable.
If you have an in/out BSTR parameter, I don't think you're allowed to alter that string. Instead you should use SysAllocString to create a new one and SysFreeString the one you were passed.
|
|
|
|
|
I want to write a program in Visual C++ to transfer data between a computers and microcontroller via 10/100 Ethernet RJ-45.
What i need (libraries, or is there any help in MSDN.)
What i figured out is that i need "winsock" for programming.(TCP client and TCP Server)
Where should I start.
thanks
|
|
|
|
|
This message board is really for discussion of the Component Object Model (COM) and programming server components and client applications. You'll probably get better results on the Visual C++ forum[^].
|
|
|
|
|
I would like to use namespaces in the IDL file, instead of MyInterface I would like to use MyNamespace::MyInterface.
For example MSXML uses different namespaces.
|
|
|
|
|
IDL does not support namespaces, which are a C++ thing. IDL is designed to be language neutral. When you #import a type library, the namespace is generated by the C++ tool doing the import, not the type library.
Steve S
Developer for hire
|
|
|
|
|
Steve S wrote: When you #import a type library, the namespace is generated by the C++ tool doing the import, not the type library.
But how does the C++ tool (MSVC) knows which namespace to use if I #import "MSXML*.dll"? That info must be in the dll? 
|
|
|
|
|
Because it uses the library name, which is in the IDL as
library MSXML2
{
// TLib : // TLib : OLE Automation : {00020430-0000-0000-C000-000000000046}
importlib("STDOLE2.TLB");
....
Steve S
Developer for hire
|
|
|
|
|
Hi,
I'm a beginner in COM, and have a question in my program need your help~
I use either _beginthreadex or CreateThread to create a thread in my COM dll's DLLMain function's
case DLL_PROCESS_ATTACH:
the thread will run a while loop to excute ReadDirectoryChanges for real time monitor directory,
but very wired, the whole COM dll will hang by that thread, other function in the dll can't work, because
whole dll is hang in there when excute ReadDirectoryChanges.
when I take off ReadDirectoryChanges from Com dll, use a individual simple project create a thread
run ReadDirectoryChanges is OK, but when COM dll combine with create thread run ReadDirectoryChanges,
the COM dll will hang there, so it maybe the COM thread setting problem? or any other issue?
Please help me~ Thanks~
|
|
|
|
|
You can create a thread in DllMain, but you can't wait on it. It will immediately cause the OS to try to re-enter DllMain to give the DLL_THREAD_ATTACH notification, but the new thread will wait there because it needs to acquire the Loader Lock. Your original thread will already have the Loader Lock, and will not release it until it returns from DllMain. If the first thread now tries to wait for some other event to occur that's signalled by the second thread, you have a deadlock.
Basically, don't do any work at all in DllMain. Instead, do lazy initialisation, when actually needed. In a COM object you might do this in the object's constructor, or otherwise in response to CoCreateInstance. For example, ATL offers the FinalConstruct method to allow you to do extra initialisation after the constructor has run but before CoCreateInstance returns.
Finally recall that interface pointers are apartment-relative. If calling back into a client from a worker thread, you need to make sure the call is marshalled correctly. See the Global Interface Table for an idea of how to do this.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
