|
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.
|
|
|
|
|
|
BY THE NAME OF ALLAH ,
i am asking for any new Idea for my graduation project , iam in computer science dep. i want in any field so plz any One know
tell me . i will be thankful .
thnkx , amal emam
|
|
|
|
|
I am having some difficulty in my C++ app with memory management. Currently the client app sets up a struct **pPointer that is passed to the COM+ method on the server. The server then reads a database and creates a record set. This record set is processed and the server then CoTaskMemAlloc’s space for each of the processed records. The array of pointers is then passed back to the client.
The pointers all seem to be marshaled fine. The data is processed, and then I CoTaskMemFree the pointers, and release the Access Object to decrement the object reference count. Even though the object seems to have no more references to it (ie the object is no longer spinning in Component Services), the server (dllhost.exe) is still holding on to the memory that was allocated on the server. After about 30 minutes the memory is eventually free’d. However the memory use is very large and multiple clients are utilizing the system. It does not take long to run out of resources and the server crashes with a ‘COM Surrogate error’ . My guess is that when the server runs out of memory, it errors and returns a NULL pointer. As Windows is trying to marshal the null pointer, the error situation occurs (but this is just a guess, it could be a bad uninitialized pointer).
I need to figure out how to free the memory on the COM server after I am done with it, so that it can be released. Any help would be greatly appreciated.
Client Side Code Snippit:
<br />
hr = CoCreateInstance( CLSID_ValuesAccessObject,<br />
0,<br />
CLSCTX_ALL,<br />
IID_IValuesAccessObject,<br />
(void**)&m_pidsrtval );<br />
<br />
...<other processing>...<br />
<br />
hr = m_pidsrtval->GetAllValues( GetDbConnectionString(),<br />
&nValues,<br />
&pspdcrtbv );<br />
<br />
<br />
...<other processing>...<br />
<br />
for( int i=0; i<nValues; i++ )<br />
{<br />
SPDCRTBV *paspdcrtbv = &((*ppsptbvValues)[i]);<br />
<br />
CoTaskMemFree(paspdcrtbv->pdvQualifiers);<br />
paspdcrtbv->pdvQualifiers = NULL;<br />
<br />
CoTaskMemFree(paspdcrtbv->pdvFacts);<br />
paspdcrtbv->pdvFacts = NULL;<br />
<br />
}<br />
<br />
CoTaskMemFree(pspdcrtbv);<br />
m_pidsrtval->Release(); <br />
Chris
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
