|
|
| Hi All, I have a program which uses the IE engine to display HTML docs in it's window. It uses COM/ATL to interface to IE. Is there a function I can call which would return to my program the highlighted text in the displayed HTML doc? Also, does anyone know of a good reference (maybe a book?) that describes how the interface to the IE engine works? Thanks in advance for any ideas, Melena 
|
|
|
|
|
Hi Melena,
So your program has IWebBrowser embeeded inside to render the HTML pages?
To retrieve the highlighted (selected) text you must query for an interface "IHTMLSelectionObject", once you get the interface pointer then check the type of this selection using IHTMLSelectionObject::Type. It could be "Text" or "Object"
Once you get d valid pointer you must create the range for the current selection using "IHTMLTxtRange = IHTMLSelectionObject.createRange" and here is your desire result "IHTMLTxtRange::Text" this would return you the highlighted (selected) text.
Does this helps you ?
Enjoy !
Cheers,
Vishal
|
|
|
|
|
Thanks Vishal, that helps a lot. It looks very similar to getting the selected text from Javascript.
|
|
|
|
|
Hello,
im new to MFC and ActiveX and such 
I would like to write a simple opengl activeX control that i can render a cube to, and imbed in a Web page (and the cube spins etc etc), i have seen alot of examples (there is one on this site) but i cannot get them working (xcept through vb)
Are there any samples/basecodes around that i can learn from?
Also, i can create an opengl window with an SDI MFC project; but where does OpenGL anchor to for an activeX application (there is no default window?)
Can someone steer me in the right direction plz
Cheers
Muncher 
|
|
|
|
|
I am new to COM. I tried creating the COM objects without using ATL wizards. As the way explained in the article "COM from scrach - part 2".
I try connecting with the server obejct from the client ,by calling the COCreateInstance() or CoGetClassObject() methods, i get the error saying "The specific module could not be found."
I registered the class too. what is this error?? How to rectify it?
|
|
|
|
|
You can try COCreateInstanceEX.
HRESULT CoCreateInstanceEx(
REFCLSID rclsid, //CLSID of the object to be created
IUnknown *punkOuter, //If part of an aggregate, the
// controlling IUnknown
DWORD dwClsCtx, //CLSCTX values
COSERVERINFO *pServerInfo, //Machine on which the object is to
// be instantiated
ULONG cmq, //Number of MULTI_QI structures in
// pResults
MULTI_QI *pResults //Array of MULTI_QI structures
);
|
|
|
|
|
Hi,
I got it right. Its problem with the path of the dll. Dll was not loaded in the path specified in the registry.
Thanks.
|
|
|
|
|
Hi, there. I'm a COM noob, and I was hoping I would be able to get some on something I'm working on..
I've managed to create a prototype IDL and get a simple COM server/client up and running. However, I've been having trouble finding help for what I'm trying to do next - making my IDL file support multiple server implementations.
Looking at the client's perspective, what is the best way to support multiple server implementations of the same IDL on a given system? In other words, I'm considering a situation where my client needs to distinguish between more than one registered "server.dll," while sticking with just one IDL file...
e.g.:
I define an IDL file. I give it to two separate people, who both implement a COM server. I register both resulting DLL files on my system. How can I make my client cope with this situation?
Perhaps I'm thinking about this the wrong way... In any case, suggestions would be much appreciated!
|
|
|
|
|
If your two separate people are both implementing COM servers, which have the same interface as defined in the IDL, then you need to register one or the other DLL and which ever DLL is the last one registered will be used.
If however the two implementations do different things, despite having the same interface, then you need to use two IDL files with different GUIDs. In the client program, when you call CoCreateInstance(), specify the appropriate CLSID.
|
|
|
|
|
Ah, I see. Thanks for clearing that up.
|
|
|
|
|
Hello Vertig0,
My post here is written with due respect to my fellow developers including "Anonymous". However, I do seriously beg to differ with "Anonymous"'s answers to you which, in my sincere and humble opinion, are incorrect.
I'll go through his answers first to set the record straight and then I'll go through the original questions that you posted. Finally, I'll provide some of my own extra inputs. I have also written a set of sample codes to illustrate my points and would be glad to email it to you. My email address will be provided below.
OK, let's go through "Anonymous"'s answers :
Anonymous wrote : "If your two separate people are both implementing COM servers, which have the same interface as defined in the IDL, then you need to register one or the other DLL and which ever DLL is the last one registered will be used."
My comments : This is not correct. Two or more (multiple, in fact) COM objects housed in separate (or even the same) DLL(s) may implement the same interface AND they can ALL be registered on the same machine, live side by side and be used separately or simultaneously by a client application.
Just imagine this, vertig0 : ALL COM objects must implement IUnknown. If what Anonymous said was true, then only one object can be registered and used at one time. What kind of a COM world would we be living in ?
Anonymous wrote : "If however the two implementations do different things, despite having the same interface, then you need to use two IDL files with different GUIDs. In the client program, when you call CoCreateInstance(), specify the appropriate CLSID."
My comments : what else is the purpose of providing two or more implementations of one published interface but to treat them as providing two or more versions of the same expected functionality ? Still, vertig0, the central idea is to maintain ONE interface (with a constant IID) coded in ONE IDL file.
Anonymous wrote : "In the client program, when you call CoCreateInstance(), specify the appropriate CLSID.".
My comments : this is exactly how a client would get hold of a specific interface implemented by one particular COM object. However, the IID of the interface -must- remain the same. It is the CLSID that is different.
OK, vertig0, now onto your questions :
vertig0 wrote : " However, I've been having trouble finding help for what I'm trying to do next - making my IDL file support multiple server implementations."
My comments : my sample codes will show you how to achieve this.
vertig0 wrote : "Looking at the client's perspective, what is the best way to support multiple server implementations of the same IDL on a given system? In other words, I'm considering a situation where my client needs to distinguish between more than one registered "server.dll," while sticking with just one IDL file..."
My comments : The CLSID of the specific COM server (which implements the interface) is what you would use to distingusish between more than one registered "server.dll".
The central point is to enable your client code to create instances (via CoCreateInstance(), etc) of the various COM objects that implement your interface. You differentiate between the versions of the interface implementation by the CLSID. My sample codes will illustrate this.
Finally :
vertig0 wrote : "Perhaps I'm thinking about this the wrong way... In any case, suggestions would be much appreciated!"
My comments : you are thinking about this the right way, vertig0. It is most intuitive and is very much in line with Object-Oriented development principles.
Send an email to me, vertig0, and I'll email you the sample codes. Here is my email address :
bio_lim_2004@yahoo.com
Again, my assurance of full respect to Anonymous.
Best Regards,
Bio.
|
|
|
|
|
Hi There,
I have similar kind of question, that with one IDL file.
I need to create different implementation, but I am wondering is there a way to implement a server using C# for same IDL.
Thanks,
Akth
|
|
|
|
|
Hello Akth,
I do believe this is possible. COM and the .NET platform do interoperate well and I believe this extends to COM interfaces being implementable in C#. Let me do some research and experimentation and get back to you on this.
Best Regards,
Bio.
|
|
|
|
|
Hello Akth,
Thanks very much for the research and knowledge sharing. For the benefit of other readers, I'm summarizing our findings :
1. A COM interface defined in an IDL can be implemented by a .NET component. In order to implement the COM interface in a .NET language, C# say, the COM definitions contained in the IDL must be converted to compatible C# definitions.
This is achieved by creating a Primary Interop Assembly for the TYPE LIBRARY of the COM IDL and then referencing this PIA inside the C# project. The following are specific steps required for this :
1.1 First creating a strong name key (.snk) file. The PIA will need to be installed into the Global Assembly Cache (GAC). Hence, it needs to be signed. A .snk file is needed for the signing process. Use the sn.exe .NET utility to generate a .snk file. For example :
sn -k ObjectInterfaces.snk
1.2 Once a strong name key file is generated, we can proceed to create the PIA. This is achieved by using the tlbimp.exe .NET utility. Use the /keyfile option (to specify the .snk file we just created) and the /primary option to specify that we want to create a PIA. For example :
tlbimp ObjectInterfaces.tlb /sysarray /out:Interop.ObjectInterfaces.dll /keyfile:ObjectInterfaces.snk /primary
The above command line will generate a PIA with filename Interop.ObjectInterfaces.dll.
1.3 Now that the PIA is created, we will need to install the PIA into the Global Assembly Cache (GAC). This is accomplished by using the gacutil.exe .NET utility. For example :
gacutil -i Interop.ObjectInterfaces.dll
2. With a GAC-installed PIA in hand, we can now reference it inside our C# project. Use the Project|Add Reference menu to do this.
2.1 Once this is done, the various COM interface and other IDL definitions will be translated into C# types. You can see this inside the Object Browser.
2.2 You will now need to define a C# class that implements the intended COM interface. Let's say your C# class is Class1 and it is defined inside the CSharpImpl01 namespace. The resultant COM-interface C# implementation will have the progid "CSharpImpl01.Class1".
3. Once you have created your C# .NET component, CSharpImpl01.dll say, it cannot be used directly as a COM component in a COM client application. It is, after all, a .NET assembly consisting of BYTE CODES.
3.1 It can, however, be created and used by a COM client with the help of the Microsoft .NET Runtime Execution Engine (mscoree.dll). The resultant object will look and feel just like any ordinary COM object (to a client).
3.2 However, in actual fact, it remains a .NET component and what gets passed to the COM client is actually a proxy.
3.3 In order that mscoree.dll be able to load CSharpImpl01.dll and more specifically, the "COM object" with the progid "CSharpImpl01.Class1" on request, the usual COM information for it must first be registered.
3.4 This is done by using the regasm.exe .NET utility. For example :
regasm CSharpImpl01.dll /tlb
The /tlb option will make regasm generate a COM Type Library file for CSharpImpl01.dll. This type library file (i.e. CSharpImpl01.tlb) can be used by a COM client for import purposes.
3.5 Take note that regasm will generate a COM CLSID for "CSharpImpl01.Class1" and store the usual COM registration information plus some .NET specific information. If you look up the "InprocServer32" registry entry for the CLSID, you will note that the server is NOT CSharpImpl01.dll. It is mscoree.dll instead.
3.6 That's right, it is the .NET Runtime Execution Engine that serves as the COM server. It acts as the middle-layer between your COM client and the .NET assembly CSharpImpl01.dll.
3.7 Finally we will also need to install the CSharpImpl01.dll assembly into the Global Assembly Cache. This is done so that mscoree.dll can locate your assembly. This is done by using the gacutil.exe utility, for example :
gacutil -i CSharpImpl01.dll
3.8 Note also that because the C# project had made a reference to the PIA interop.objectinterfaces.dll, CSharpImpl01.dll will be dependent on it. This is also why we had earlier installed the PIA.
4. Your COM client can now either import the CSharpImpl01.tlb type library (in order to reference the C#-to-COM object CLSID) or it can use the "CSharpImpl01.Class1" progid to instantiate the new "COM object".
I certainly hope the above explanations will be helpful to all.
Best Regards,
Bio.
|
|
|
|
|
Anyone have any clues to try and solve this. I have a C++ application written as a COM object that works great in VB6, yet when it is referenced in a .NET project, this disturbing message appears.
converting the type library to a .net assembly failed
Thx
|
|
|
|
|
how to write a shell extension ( for example context menu) in masm (without using the CoLib)
|
|
|
|
|
|
I am Create Instance in DCOM Client.Show me my code:
// Create the server locally
/*HRESULT hResult = m_pChatSvr->CreateInstance(CLSID_ChatSvr);*/
HRESULT hResult = CoCreateInstanceEx(CLSID_ChatSvr, NULL,
CLSCTX_LOCAL_SERVER | CLSCTX_REMOTE_SERVER, &serverInfo, 1, &qi);
if (FAILED(hResult))
{
//handle Error
}
When Program is Running in DCOM CLient,visual C++ show me hResult
='-2147024891' and "E_ACCESSDENIED"
Please tell me What about it!
|
|
|
|
|
Hi,
I need to build up a class in a COM DLL. An eg. what I want to do is
|-----Penguin
|-----Non Flying Bird-|
| |-----(Can't think of another Eg.)
BIRD -|
| |-----Eagle
|----Flying Bird-|
|-----Crow
I am still new to COM. I am using the VC++ ATL COM Appwizard. I managed to do a coclass for Bird and I managed to create and use this object in VB.
But how do I build the other classes on this? Can I achieve this by changing the
"interface IFlyingBird : IDispatch" line
to
"interface IFlyingBird : IBird"?
Or what is the proper method of doing what I want to achieve above?
And hoe do I declare virtual functions?
Any help will be very much appreciated. Thanks in advance....
|
|
|
|
|
Hi All,
We have a imaging system application with a combination of COM components, extension dll and stand alone executables. Do we have a way of profiling the thread interaction at run time. Are there any tools available for this. My need is to do a profiling of thread interaction within and across processes.
Regards
Rajdeep
|
|
|
|
|
Hello:
I need to mux two mono audio pcm inputs into one stereo output. Does anyone have a simple DirectShow sample code that I can follow? Many Thanks.
Best Wishes,
Taiwu
|
|
|
|
|
i'm working on a project and i've got dis scenario, I need to read input from a Port -(COM(i)- where i can be any of the ports) and write it to a user(interface -may be a textbox). i'm using vb.net and not cracking it yet.any ideas on how can i crack dis
kwn
|
|
|
|
|
I've been given a VB example of how to use a hidden interface on a COM object. I need to implement this code in C++. The VB code uses the InMemoryRecordset object.
Dim objIMRS As New InMemoryRecordset
When I create a C++ wrapper class the InMemoryRecordset interface is ignored, but an IInMemoryRecordset interface class is created. InMemoryRecordset/IInMemoryRecordset don't exist in registry. The OLE Viewer sees the following in the TLB.
[
uuid(3DCB2383-3BF0-11D1-9211-006097383187),
hidden,
dual,
nonextensible
]
dispinterface IInMemoryRecordset {
properties:
methods:
[id(0x60020000), propget, hidden, helpstring("Returns the output Recordset.")]
GRecordset* OutputRecordset();
[id(0x60020001), hidden, helpstring("Append new read only field")]
GField* AddReadOnlyField(
[in, optional] VARIANT Collating,
[in, optional] VARIANT SourceDatabase,
[in, optional] VARIANT SourceTable,
[in, optional] VARIANT SourceField);
[id(0x60020002), hidden, helpstring("Append new read write field")]
GField* AddReadWriteField(
[in, optional] VARIANT Collating,
[in, optional] VARIANT SourceDatabase,
[in, optional] VARIANT SourceTable,
[in, optional] VARIANT SourceField);
[id(0x60020003), propput, hidden, helpstring("Indicates if ReadOnly property of a field is disabled ")]
void ReadOnlyDisabled([in] VARIANT_BOOL rhs);
};
How can I create an instance of an InMemoryRecordset object when I can only see it in VB?
Thanks
Dave
Dave
http://www.unit-conversion.com
|
|
|
|
|
Is there any method to connect to any web browser, not just IE. For example FireFox, Opera e.g
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
