|
What about naming that interface in your post ?
Back to real work : D-24.
|
|
|
|
|
Ok, here it goes 
The next code is the declaration of the interface:
CODE
_____________________________________________________________________________
static const GUID IID_ISomething =
{ 0x5a9fc16e, 0x69b0, 0x4092,{0x9b, 0x17, 0x0e, 0xae, 0x91, 0x9c, 0x61, 0x2d}};
DECLARE_INTERFACE_(ISomething, IUnknown)
{
STDMETHOD (func1) (THIS_
unsigned char* Data, int width, int height
) PURE;
STDMETHOD (func2) (THIS_
int* MyFeature
) PURE;
STDMETHOD (func3) (THIS_
int Feature1, int Feature2, float *Distance
) PURE;
};
_____________________________________________________________________________
And the class is declared as follows:
CODE
_____________________________________________________________________________
static const GUID CLSID_Something =
{0x5b4f902f, 0x0d14, 0x44df, {0x99, 0x51, 0x1a, 0x18, 0x70, 0x4f, 0x3c, 0x21}};
class CSomething : public ISomething
{
public:
//IUnknown interface
HRESULT __stdcall QueryInterface(REFIID riid , void **ppObj);
ULONG __stdcall AddRef();
ULONG __stdcall Release();
//ISomething interface
STDMETHODIMP func1( unsigned char* Data, int width, int height);
STDMETHODIMP func2( int *MyFeature);
STDMETHODIMP func3( int Feature1, int Feature2, float *Distance);
};
|
|
|
|
|
This code looks pretty much ok, but there are many things to figure out :
- if you try dumpbin /exports, do you see 4 exported function names ?
- do you have an IDL file ?
- do you use ATL for the registration ? and regarding this, what is the implementation of DllRegisterServer() and DllGetClassObject() ?
I guess that, instead you start zipping the whole stuff and upload it somewhere, you could get a bit further by putting a breakpoint in DllRegisterServer() (I assume your component is a DLL, not a .exe). At least if this gets called when you do regsvr32, that's because things are about right.
Then, put a breakpoint in DllGetClassObject(), there you should see somehow a class factory create for you an instance of CSomething. If you are using ATL, you'll have to put a breakpoint in the plain ATL code.
Back to real work : D-24.
|
|
|
|
|
Yes, I have my exports, declared in exports.def and defined in exports.cpp (where I have my DllGetClassObject() which creates an instance to the Factory class).
Inside Createinstance() of the Factory, a new object of my dll is created. Later, it goes inside the QueryInterface() of me Object dll. The next interfaces are called: ISomething, IMarshall, IUnknown, and more.... y only have implemented the handling for IUnknown and ISomething, therefore, the rest of them are returned as E_NOINTERFACE. What should i do?
I am not using IDL file.
I have bebugged also the registration of the DLL and everything seems ok, the DllRegisterServer() seems to work.
|
|
|
|
|
Hello,
I am using IStream interface to read and write data objects into a structured storage file.
pOrderInfo->Write(&cust1, sizeof(cust1), NULL);
pOrderInfo->Read(&cust2,sizeof(cust2),NULL);
Can some one tell me what should I do if I want to update information in cust1 structure and save it back to file ?
Say, I want to change cust1.Name = "new name".
thanks,
|
|
|
|
|
I want a COM control held a FormView and CMDIChildFrame. And the control provides a interface, the container App(a MDI App) can use the interface gain the pointer to the CMDIChildFrame from the control. Then the container App can use the CMDIChildFrame as its own child frame.
|
|
|
|
|
Please, suggest me where I can find or purchase documentation or SDK for MS-Word 97 and 2000 DOC-file format. May be you can also suggest me where I can find or purchase any component, which can write data directly into DOC-file without using MS-Word OLE Automation Server functions, or which can directly convert MS-Word RTF-file into MS-Word DOC-file without using MS-Word OLE Automation Server functions.
|
|
|
|
|
I need to write an extensible app. My app uses services provided by one or more plug-ins written as COM components. Users can write a plug-in and then install it. That's going pretty well so far but it suddenly struck me that I'm not doing any real verification. In other words, if one of the user-written COM plug-ins wasn't a "genuine" one, how would my application know? Further, if I provided one or two COM objects that offered services to plug-ins and to the application I need to ensure plug-ins haven't got access to certain methods/objects that the application has access to.
It seems that COM offers excellent security for distributed object requests but local security only consists of ensuring the user has access to a particular COM object.
To summarise then:
1. How do I verify a COM component's source? In other words, how do I verify that a COM component which has been "discovered" by my application on initialisation, is geuine?
2. How do I allow one COM object to access another COM object's services, and denying it other services?
Thanks for reading and any input gratefully accepted 
"The folly of man is that he dreams of what he can never achieve rather than dream of what he can."
|
|
|
|
|
1. A COM interface is a contract between a client and a server. You have to trust it somehow. If you want to make sure people use badly the plugin architecture you provide them, force them to sign (public keys, etc.). You have docs on MSDN for that.
2. Use DCOMCNFG.EXE to create interactively the proper RunAs registry keys so certain COM services are run with degraded priviledges.
How low can you go ?
(MS rant)
|
|
|
|
|
I am newbie to COM, What i want to Do.?
in Msn Messenger : renji12renji@hotmail.com
|
|
|
|
|
Renjith r wrote:
What i want to Do.?
Wow - there's a question. You should buy a good book, I recommend 'creating lightweight components with ATL' by Jonothan Bates. ATL is a template library, it's the ONLY way to be creating COM components.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
During last 10 years, with invention of VB and similar programming environments, every ill-educated moron became able to develop software. - Alex E. - 12-Sept-2002
|
|
|
|
|
Christian Graus wrote:
it's the ONLY way to be creating COM components.
Ain't that a tease to hell! 
How low can you go ?
(MS rant)
|
|
|
|
|
*grin* A general question demands a vague answer.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
During last 10 years, with invention of VB and similar programming environments, every ill-educated moron became able to develop software. - Alex E. - 12-Sept-2002
|
|
|
|
|
AnyWay Thanks For Ur Kindly info..
Thank you
in Msn Messenger : renji12renji@hotmail.com
|
|
|
|
|
Hello All,
In my project, I am using IStorage::CreateStream(). What I am doing is creating storage, and adding a file into the stream. For that I am using CreateStream, but the problem is, if the file name is large my program is crashing. I read MSDN, that CreateStream can't handle large filename (more than 31 characters.) Its giving me an error invalid pwcsName.Is there anyway to handle this problem???
Or is there any alternative which can solve this problem. Please, help.
Thanks,
|
|
|
|
|
I answered this in the C++ section: here
"The greatest danger to humanity is humanity without an open mind."
- Ian Mariano
http://www.ian-space.com/
|
|
|
|
|
Note :
Storage and stream names cannot contain the characters /,\,:, or !. If the first character has an ASCII value of the less than 32, the element is marked as managed by some agent other than the owner.;P
|
|
|
|
|
Hi All,
I was trying to write component in which I perform database access only once and return the IRowset* to client. In subsequent client requests, CCommand is built using client given IRowset* without making d/b connection again.
Here is how it goes.
I built CCommand<Accessor<CMyAccessor> > and Opened it using a CSession-obj and extracted IRowset* and other public members from CCommand. I closed CDataSource,CSession not CCommand.
Later I want to build CCommand<> again by assigning IRowset* etc to it.
The problem is I am able to iterate CCommand but CMyAccessor-members the current record holds are garbage values.
Does anyone know the missing steps? Please let me know!
Here goes the code.. (VC++/ATL/SQL Server OLEDB Driver)
//--------------------------------------------------------
// CCommand members to be used in 2nd section
ICommand *pCommand=0;
IRowset *pRowset=0;
_ATL_ACCESSOR_INFO AccInfo={0};
//---------------------------------------------------
//1st Section opens CCommand using session
//---------------------------------------------------
CDataSource connection;
CSession session;
CCommand<CAccessor<CMyAccessor> > cmd;
// establish connection and session
// command opened successfully
cmd.Open(session,"select * from tab1");
//Extract members
pCommand = cmd.m_spCommand.Detach();
pRowset = cmd.m_spRowset.Detach();
AccInfo.bAutoAccessor =
cmdCalDefault.m_pAccessorInfo->bAutoAccessor;
AccInfo.hAccessor = cmdCalDefault.m_pAccessorInfo->
hAccessor;
cmd.Close(); // do nothing as such
session.Close();
connection.Close();
//---------------------------------------------------
//2nd Section builds CCommand using IRowset*
//---------------------------------------------------
CCommand<CAccessor<CMyAccessor> > cmd2;
//Assign to CCommand
cmd2.m_spCommand = pCommand;
cmd2.m_spRowset = pRowset;
cmd2.m_pAccessorInfo = &AccInfo;
cmd2.m_nAccessors = 1;
// Iteration of cmd2 gives garbage values
//--------------------------------------------------------
Regards
Rohit Arora
VC++ Team Member
rohita@dsrsolutions.com
|
|
|
|
|
I was developing a COM. It's a DLL. Also I include MFC support.
I've choosen Apartment threading model. Dual Interface support. And no Aggregation support.
The business logic is written with the help of CInternetSession class. Actually I was trying to get the source of a URL.
Now after implement the business logic. I build the COM DLL.
After building the the COM DLL successfully. I used the COM with VB. The VB program has a GUI.
I don't know why it freezes the GUI when it start retreiving the source of the URL. As the COM Framework covers the threading detail itself.
Any body has the answer
Dammy More
|
|
|
|
|
Hi, I want to create an application which will have three "services" (not necessarily NT services). I need fast and frequent IPC calls, and think that COM is probably the way forward for this.
One of these services will need to communicate with the two others, and those two others will need to know about the first.
When defining the interfaces for these services, should I create a single IDL that defines all three? Surely this will reduce include complexity? Am I correct in thinking that the best way to do so is to derive from IUnknown - or should I be aiming at IDispatch?
Having defined that IDL, is the best way to attempt to compile that into a .tlb and import it in the other projects?
I'm relatively new to COM so please excuse my lack of knowledge...
Thanks in advance for any advice or suggestions you can give me. I am trying to work my way through Essential COM while programming with ATL7 - something which doesn't exactly ease the process of getting into COM
--
Simon Steele
Programmers Notepad - http://www.pnotepad.org/
|
|
|
|
|
Simon Steele wrote:
Hi, I want to create an application which will have three "services" (not necessarily NT services). I need fast and frequent IPC calls, and think that COM is probably the way forward for this.
One of these services will need to communicate with the two others, and those two others will need to know about the first.
When defining the interfaces for these services, should I create a single IDL that defines all three? Surely this will reduce include complexity? Am I correct in thinking that the best way to do so is to derive from IUnknown - or should I be aiming at IDispatch?
Having defined that IDL, is the best way to attempt to compile that into a .tlb and import it in the other projects?
I would go for a single IDL and .TLB because there are inter-dependencies between the interfaces, as it seems it is your first ATL project.
About the IDispatch, using ATL, I would definitively recommend you to declare your interfaces as dual, so they are exposed both as custom interfaces (derive directly from IUnknown) and have the IDispatch implemented too. Take care and only use automation types, this makes things easier for your clients. You'll never know when your COM object will be used from scripting clients or beginner VB programmers, and God knows why, they find IDispatch easier...
The ATL COM wizard have an option that generates the dual interfaces declaration and the IDispatch implementation for you, so, normally this is a no-brainer.
Q261186 - Computer Randomly Plays Classical Music
|
|
|
|
|
Daniel Turini wrote:
About the IDispatch, using ATL, I would definitively recommend you to declare your interfaces as dual
Thanks, I'll try it. I'm only working on experimental projects at the moment so it doesn't matter too much if I get it wrong and need to start again. But you know how these experimental projects suddenly become sold products!
Some of this stuff is really clever, I am being repeatedly amazed
Do I need to separate the interfaces from the classes in this separate IDL file? I might want to create multiple objects that expose the same interface and am not entirely clear on how to do this sanely!
Thanks again for your help,
--
Simon Steele
Programmers Notepad - http://www.pnotepad.org/
|
|
|
|
|
Simon Steele wrote:
One of these services will need to communicate with the two others, and those two others will need to know about the first.
If each service is a COM object, then you'll have 3 idl files. Reusing idl file from one COM service into another is not an option since GUID, LIBID, CLSID, IID would be the same. It's sad MIDL is really limited when it comes to sharing idl interfaces, although you have the import and importlib statements.
Simon Steele wrote:
Thanks in advance for any advice or suggestions you can give me. I am trying to work my way through Essential COM while programming with ATL7 - something which doesn't exactly ease the process of getting into COM
I recommend to stay low-level. You'll get code skeletons from the book "Inside COM" MS PRESS, which I recommend. And this source code doesn't obfuscate at all what is done, unlike ATL.
ATL is fast for coming up with COM servers, but the learning curve is huge (in fact, you won't get your own ATL COM server running without actually hacking what ATL does, which requires huge time when you don't know it).
That said, I can't come up at the moment with a decent listing on CodeProject who would have just that, but beware of code filled with macros...
How low can you go ?
(MS rant)
|
|
|
|
|
If I split the interface and class definitions, then surely I can have a single .IDL file for the three which defines the interfaces? Then each can implement classes and libraries which contain implementations of those interfaces? As I said I'm new to this, but it does seem to be hinted at in the book I'm reading.
__Stephane Rodriguez__ wrote:
You'll get code skeletons from the book "Inside COM" MS PRESS,
I'm trying to make my way through Essential COM by Don Box which is great, but the shear amount of code to do this stuff without ATL seems incredible!
--
Simon Steele
Programmers Notepad - http://www.pnotepad.org/
|
|
|
|
|
Simon Steele wrote:
If I split the interface and class definitions, then surely I can have a single .IDL file for the three which defines the interfaces? Then each can implement classes and libraries which contain implementations of those interfaces? As I said I'm new to this, but it does seem to be hinted at in the book I'm reading.
Yes, at least in theory, and it will even compile. But I am not sure it will run. I had this problem, and the .tlb was not including the idl stuff I was including in the main idl. So it was ok for compilation time. But only for compilation time.
Simon Steele wrote:
the shear amount of code to do this stuff without ATL seems incredible!
That's a fake. May be I publish COM skeletons sometimes in the future so you figure out it's damn light, easy, DEBUGGABLE (unlike ATL macros), neat and reusable. (as you can see, I am not a big fan of ATL  ).
How low can you go ?
(MS rant)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
