|
tasleem143 wrote:
activeX (internet activex) made in the vc or vb are capable of self registering. or had to something extra to
register them.
The components are capable of self registering themselves, provided they have the necesary permissions to do so.
The Internet Activex control should be singed by any of the singing authorities otherwise when it tries to register itself then u will get a security warning.
tasleem143 wrote:
what functions will be used to register them
To register an control use "Regsvr32.exe"
tasleem143 wrote:
i want to know that when user will visit my page then ocx will be selfdownloaded
and selfrejisted to that client pc. or what will happen.
For a component to download itself on to the client machine, create a Cabinet (.cab) file for that component along with the .inf file, mentioning that the control has to register itslef once it get downloaded on to the client machine.
place "cab" file in the virtual directory.
|
|
|
|
|
hi
i want to know how to make the (.cab) file for the component along with inf file. and in the codebase attribute of the object tag i should refer to that site where cabfile is placed. and in the cab file ocx will be present.
ddd
|
|
|
|
|
Hi,
Inorder to make the cabinet file u need "Microsoft Cabinet Software Development Kit. you can download it from the following location:
http://support.microsoft.com/default.aspx?scid=KB;en-us;310618&[^]
tasleem143 wrote:
i want to know how to make the (.cab) file for the component along with inf file
The following entries have to be made in the (.inf) file
<br />
[version]<br />
signature="$CHICAGO$"<br />
AdvancedINF=2.0<br />
<br />
[Add.Code]<br />
YourComponent.dll=YourComponent.dll<br />
<br />
[YourComponent.dll]<br />
file-win32-x86=thiscab<br />
clsid={CLSID of the component}<br />
FileVersion=1,0,0,1 <br />
RegisterServer=yes<br />
"YourComponent.dll" is the name of your component
Save the above as file as "YourComponent.inf" file
Run the "cabarc" utitlity as following.
cabarc n CabinetFileName.cab YourComponent.dll YourComponent.inf
it generates a cab file in the current directory.
place the cab file in the virtual directory.
tasleem143 wrote:
the codebase attribute of the object tag i should refer to that site where cabfile is placed.
declare the <object> Tag as following:
<object id="<i">ObjectName height=100 width=100
classid="CLSID:CLSID of the component"
CODEBASE="CabinetFileName.cab#version=1,0,0,1">
Tiru
|
|
|
|
|
hi
thanks for ur help i had downloaded that from site. i had bid of confusion. u said that in making the inf file i should replace the
"YourComponent.dll" with myown component. but my component extension in .ocx not .dll.
2nd u specifie that i should place the cab file in the "virtual directory". i want to know that what is that virtual directory. is that is the
place where mysite in rejistered or mysite folder.
third in the codebase tag suppose mysite is rejisted as yahoo.com and cabfile name is test then i should write this on tag
CODEBASE="http://www.yahoo.com/test.cab#version=1,0,0,1">
if want to check that locally on my computer then i should install the iis and then can check that or without that is possible. and in the
code base tag i should write
CODEBASE="C:\test.cab#version=1,0,0,1">
i had tried to check that locally without installing the" iis" it did not worked
by making the cabfile as u specified and in the cabfile the ocx and inf were presetnt. with procedure u specified.
ddd
|
|
|
|
|
tasleem143 wrote:
"YourComponent.dll" with myown component. but my component extension in .ocx not .dll
yeah u can mention your .ocx file name instead of the .dll file.
tasleem143 wrote:
i want to know that what is that virtual directory
Virtual directory is the folder that u create in your web site. it contains all the web pages.
Regarding the Code base, u just need to mention the name of the cab file and its version.
tasleem143 wrote:
i had tried to check that locally without installing the" iis" it did not worked
by making the cabfile as u specified and in the cabfile the ocx and inf were presetnt. with procedure u specified.
inorder to test it on the local machine u need to install IIS on it and follow the earlier procedure.
|
|
|
|
|
hi
thank for ur useful time. it works properly.
when u had not replied on sundays then i searched the microsft soft site for that purpose then i found and article related to the cab file in which all procedure was explained. i read that and i want that with the cab file all the dll required to run the mfc programs ie mfc42.dll should be also downloded and extracted automatically.
it was explained in that but icannot understand that all dll's (mfc42.dll and other 2) and on inf should be packed in seperate cabfile alongwith the inf file or in same cab file in which ocx is present. it is below i dont know
ddd
|
|
|
|
|
|
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!
|
|
|
|
|