query interface in VB?
-
Guyz, I remember working with C++ COM, I could use QueryInterface to find whether an interface is supported in a component. Is there a similar mechanism in VB too? If not what would be a best way to do. \Thnx! :zzz:
-
Guyz, I remember working with C++ COM, I could use QueryInterface to find whether an interface is supported in a component. Is there a similar mechanism in VB too? If not what would be a best way to do. \Thnx! :zzz:
LOL, This comes along with a question of mine that probably can answer your question :) If i'm not crazy, it should be possible to query for interfaces using CType(), and my question is related to CType. :) Say i have a COM object with multiple inherited interfaces like:
interface IFoo : IDispach { .. blah ... } interface IOtherFoo : IFoo { .. blah ... }Now, in some way i have a method somewhere that returns an IFoo object:
[id(4), propget] Foo([out, retval] IFoo ** rvIFoo);now, in VB i do
Set MyObj = someobject.Foo. Then later i doSet MyObj2 = CType(MyObj, IOtherFoo). Will MyObj2 be the IOtherFoo interface of the same instance as MyObj ? PS: From searches i've done, CType() seems to be only valid in VB.NET. Is there an equivalent to CType() in VB 6.0 ? -
LOL, This comes along with a question of mine that probably can answer your question :) If i'm not crazy, it should be possible to query for interfaces using CType(), and my question is related to CType. :) Say i have a COM object with multiple inherited interfaces like:
interface IFoo : IDispach { .. blah ... } interface IOtherFoo : IFoo { .. blah ... }Now, in some way i have a method somewhere that returns an IFoo object:
[id(4), propget] Foo([out, retval] IFoo ** rvIFoo);now, in VB i do
Set MyObj = someobject.Foo. Then later i doSet MyObj2 = CType(MyObj, IOtherFoo). Will MyObj2 be the IOtherFoo interface of the same instance as MyObj ? PS: From searches i've done, CType() seems to be only valid in VB.NET. Is there an equivalent to CType() in VB 6.0 ?hi QueryInterface is available in VB. Consider the CoClass below with two interfaces
coclass Calc { [default] interface Scientific; interface General; };Now in VbDim objScientific as new Calc.Scientific Dim objGeneral as Calc.General **set objGeneral = objScientific**Here the line**set objGeneral = objScientific**will Queryinterface objScientific for objGeneral and objGeneral will get a valid pointer if it is available in the CoClass. Rgds...mil10 -
hi QueryInterface is available in VB. Consider the CoClass below with two interfaces
coclass Calc { [default] interface Scientific; interface General; };Now in VbDim objScientific as new Calc.Scientific Dim objGeneral as Calc.General **set objGeneral = objScientific**Here the line**set objGeneral = objScientific**will Queryinterface objScientific for objGeneral and objGeneral will get a valid pointer if it is available in the CoClass. Rgds...mil10Whoah .. thx a lot for the information :) But if i may, let me be more specific. 1) From your sample, what if i do:
Dim objGeneral as new Calc.General Dim objScientific as Calc.Scientific Set objScientific = objGeneralWould it still be working ? 2) What if i dont have a CoClass for my object, but only an interface:interface IScientific : IGeneral { ... blah ... } interface ICalc : IDispatch { [id(1),propget] STDMETHOD(General)([out,retval] IGeneral **rvGeneral); } coclass Calc { [default] interface ICalc; }, now in my Calc coclass, i instantiate an IScientific object and i return an IGeneral pointer, which, if i understand well, return a shorter vTable. Then i run the Vb code in section 1. Will Vb do a QueryInterface on objGeneral to get an objScientific interface pointer ? I guess i should explain what i want to do more specificly. I would like to have 2 layers of information on a specific object, but i dont want someone getting access to an objGeneral to be able to cast it and make an objScientific with it. (hoping i am clear here). Maybe what i need to use containment or aggregation. I want simple users to be able to view certain object properties, while allowing admins to view more properties and have access to Modify() and Create() types of functions. -
Whoah .. thx a lot for the information :) But if i may, let me be more specific. 1) From your sample, what if i do:
Dim objGeneral as new Calc.General Dim objScientific as Calc.Scientific Set objScientific = objGeneralWould it still be working ? 2) What if i dont have a CoClass for my object, but only an interface:interface IScientific : IGeneral { ... blah ... } interface ICalc : IDispatch { [id(1),propget] STDMETHOD(General)([out,retval] IGeneral **rvGeneral); } coclass Calc { [default] interface ICalc; }, now in my Calc coclass, i instantiate an IScientific object and i return an IGeneral pointer, which, if i understand well, return a shorter vTable. Then i run the Vb code in section 1. Will Vb do a QueryInterface on objGeneral to get an objScientific interface pointer ? I guess i should explain what i want to do more specificly. I would like to have 2 layers of information on a specific object, but i dont want someone getting access to an objGeneral to be able to cast it and make an objScientific with it. (hoping i am clear here). Maybe what i need to use containment or aggregation. I want simple users to be able to view certain object properties, while allowing admins to view more properties and have access to Modify() and Create() types of functions.hi man.. 1. Would it still be working ? yes of course it will work. if a coclass say x
coclass x { [default] interface interface1; interface interface2; }contains more than one interface then through VB we can directly say "new" only to the default interface. then thru that interface we can queryinterface the remaining interfaces in that coclass. Also in a coclass there shud be only one IDispatch implimented interface. if there is more than one interface having IDispatch as base , then u shud use COM_INTERFACE_ENTRY2(IDispatch,IURInterface) macro to specify the default interface and the other interface can't be invoked thru dispid - i mean thru idispath->invoke. 2) What if i dont have a CoClass for my object, but only an interface: interface IScientific : IGeneral { ... blah ... } You can not have a com interface without a coclass. It is the basic COM rule. Then about ur requirement, if i understud u in the right way, It is not possible to make such a role based security over com interfaces. Once a client got an inteface, he can access all the remaining interfaces in that coclass. Otherwise if ur ok to go for com+ then u can set role based security. An adjustment that we can do (not a concrete solution for the prblm) is use thehiddentag in IDL. Then vb's like com object browsers can not display it. so the user will not come to know abt such an interface. but if he take the IDL of the dll, then everything will be visible. hope this will help. rgds..mil10 -
hi man.. 1. Would it still be working ? yes of course it will work. if a coclass say x
coclass x { [default] interface interface1; interface interface2; }contains more than one interface then through VB we can directly say "new" only to the default interface. then thru that interface we can queryinterface the remaining interfaces in that coclass. Also in a coclass there shud be only one IDispatch implimented interface. if there is more than one interface having IDispatch as base , then u shud use COM_INTERFACE_ENTRY2(IDispatch,IURInterface) macro to specify the default interface and the other interface can't be invoked thru dispid - i mean thru idispath->invoke. 2) What if i dont have a CoClass for my object, but only an interface: interface IScientific : IGeneral { ... blah ... } You can not have a com interface without a coclass. It is the basic COM rule. Then about ur requirement, if i understud u in the right way, It is not possible to make such a role based security over com interfaces. Once a client got an inteface, he can access all the remaining interfaces in that coclass. Otherwise if ur ok to go for com+ then u can set role based security. An adjustment that we can do (not a concrete solution for the prblm) is use thehiddentag in IDL. Then vb's like com object browsers can not display it. so the user will not come to know abt such an interface. but if he take the IDL of the dll, then everything will be visible. hope this will help. rgds..mil10Regarding the option of not having a coclass, i have to disagree with you. You are right that i need a coclass to start with. Any com server will require at least 1 coclass. But the way i understand it the purpose of coclass is to allow instantiation of an object. in my examples up there, with vb i could do 'Set myobj = new interface1' or 'Set myobj = new interface2'. But it would not be possible to do 'Set mycalc = new IScientific' But, this doesnt prevent from having a method in interface1 that returns a reference to an IGeneral or IScientific instance. Am i making sense ? DarkByte
-
Regarding the option of not having a coclass, i have to disagree with you. You are right that i need a coclass to start with. Any com server will require at least 1 coclass. But the way i understand it the purpose of coclass is to allow instantiation of an object. in my examples up there, with vb i could do 'Set myobj = new interface1' or 'Set myobj = new interface2'. But it would not be possible to do 'Set mycalc = new IScientific' But, this doesnt prevent from having a method in interface1 that returns a reference to an IGeneral or IScientific instance. Am i making sense ? DarkByte
hi I am sticking with my previous post. Ur understanding of a coclass is correct. It is to allow instantiation of an object. But u can acces an interface only after instantiating an object. So without a coclass there is no existance for an interfce. An interface is below the coclass in the hierarchy. It is just like a member function comes under its class. Without a class there is no existance/meaning in a member function right? hope this will make things more clear.. await ur opinion. rgds..mil10
-
hi I am sticking with my previous post. Ur understanding of a coclass is correct. It is to allow instantiation of an object. But u can acces an interface only after instantiating an object. So without a coclass there is no existance for an interfce. An interface is below the coclass in the hierarchy. It is just like a member function comes under its class. Without a class there is no existance/meaning in a member function right? hope this will make things more clear.. await ur opinion. rgds..mil10
Yup, i think we both understand the same thing regarding coclass uses. What i'm still not 100% convinced (althought i could do some test and make myself a possibly false opinion) is regarding QueryInterface and/or its use in VB. Now, with your example for IGeneral and IScientific, if i understand correctly, it doesnt matter how we acquired and interface pointer, if the instance behind the pointer exposes more than 1 interface, it becomes possible to reference that instance under any of its exposed interfaces. Meaning that if i get an IGeneral interface pointer to an IScientific instance, its always possible from code to access its IScientific interface by using QueryInterface(), or using the method shown earlier in VB. BTW: It's a pleasure talking with someone that has knowledge. I hope i can be of service some day. DarkByte
-
Yup, i think we both understand the same thing regarding coclass uses. What i'm still not 100% convinced (althought i could do some test and make myself a possibly false opinion) is regarding QueryInterface and/or its use in VB. Now, with your example for IGeneral and IScientific, if i understand correctly, it doesnt matter how we acquired and interface pointer, if the instance behind the pointer exposes more than 1 interface, it becomes possible to reference that instance under any of its exposed interfaces. Meaning that if i get an IGeneral interface pointer to an IScientific instance, its always possible from code to access its IScientific interface by using QueryInterface(), or using the method shown earlier in VB. BTW: It's a pleasure talking with someone that has knowledge. I hope i can be of service some day. DarkByte
Ok man, So the remaining doubt is regarding the queryinterface in vb. Just give me ur email id i will send you a sample with an ATL com and a vb client which queryinterfaces for remaining Interfaces in the CoClass. It will clear all ur doubts. Yes. It doesn't matter how we aquired the interface pointer, it is possible to Queryintface for the remaining Interfaces in the same coclass. That is the way com impliment an interface. Did you forget the fact that, all com interface should be derived from IUnknown and IUnknown contains the QuryInterface() method to get the remaining interfaces of the same object. Thanks for the compliments, it was nice to talk with you. rgds..mil10