Click here to Skip to main content
15,909,205 members
Home / Discussions / C / C++ / MFC
   

C / C++ / MFC

 
GeneralDriver architecture advice needed Pin
@Work3-Feb-05 1:48
@Work3-Feb-05 1:48 
GeneralRe: Driver architecture advice needed Pin
Antti Keskinen3-Feb-05 3:44
Antti Keskinen3-Feb-05 3:44 
GeneralRe: Driver architecture advice needed Pin
Geert van Horrik3-Feb-05 20:41
Geert van Horrik3-Feb-05 20:41 
GeneralRe: Driver architecture advice needed Pin
Antti Keskinen3-Feb-05 23:14
Antti Keskinen3-Feb-05 23:14 
GeneralRe: Driver architecture advice needed Pin
Geert van Horrik3-Feb-05 23:23
Geert van Horrik3-Feb-05 23:23 
GeneralRe: Driver architecture advice needed Pin
Antti Keskinen3-Feb-05 23:48
Antti Keskinen3-Feb-05 23:48 
GeneralRe: Driver architecture advice needed Pin
Geert van Horrik4-Feb-05 0:01
Geert van Horrik4-Feb-05 0:01 
GeneralRe: Driver architecture advice needed Pin
Antti Keskinen4-Feb-05 1:05
Antti Keskinen4-Feb-05 1:05 
Hi

Tischnoetentoet wrote:
One question left, and you are the best

I'm far from the best, but I know my stuff. Guess that's one of the hazards of being a professional Big Grin | :-D Thanks anyway Big Grin | :-D

All COM methods must return a HRESULT to the client. This is by design, because the clients use SUCCEEDED and FAILED macros to determine if they should continue with or retry the process, and the HRESULT values are designed to support these macros. This way, the client does not need to know what return values the server gives, other than the knowledge that SUCCEEDED and FAILED macros determine if it can continue using the object.

If you must return a value to indicate the amount of PLC objects, you can use a reference variable or a pointer. Just create a function that takes an int& as variable, fill in the number of devices, and return a HRESULT that the enumeration was succesfull. The client can then check the integer to know how many devices there are.

If you follow the standard, like you should, then a call chain like the one you describe is not possible, because each function must return a HRESULT. If you break the standard, you can do whatever you please, but your component is no longer COM compliant, and it might fail to work on a different language. Generally, you shouldn't require the client to build large call chains, instead, implement the HRESULT GetPLCConnection(int nIndex, IPLCDevice** pDeviceInterface). For this function, you pass the index value of the desired device and the interface pointer's address, and it returns you with a success code and a working pointer to the correct interface. IF the device doesn't exist, it NULLs the pointer and returns a failure code.

Another reason for avoiding call chains is the reference counting. Whenever a COM object refers an interface, it increments the counter. When all interfaces are released, the counter goes zero, and the object can free the class responsible for serving this interface. If you build long call chains, the reference counting will not work, and your COM object does not act like a COM object should. Again, because different languages offer different levels of access to COM, your object might work on C++ (which has pointers) but fail on Visual Basic (which doesn't have them). In general, avoid call chains when dealing with COM. It makes your code and documentation much easier to follow for those people who have used COM earlier and know the way it should function. Breaking the standard will cause professionals to life an eyebrow towards your code, even if it would still work.

Hope this helps

-Antti Keskinen

----------------------------------------------
"If we wrote a report stating we saw a jet fighter with a howitzer, who's going to believe us ?"

-- R.A.F. pilot quote on seeing a Me 262 armed with a 50mm Mauser cannon.
GeneralRe: Driver architecture advice needed Pin
Geert van Horrik4-Feb-05 1:15
Geert van Horrik4-Feb-05 1:15 
GeneralCharting Pin
_Tom_3-Feb-05 1:24
_Tom_3-Feb-05 1:24 
GeneralRe: Charting Pin
David Crow3-Feb-05 3:47
David Crow3-Feb-05 3:47 
GeneralRe: Charting Pin
krmed3-Feb-05 6:51
krmed3-Feb-05 6:51 
GeneralGet system properies at runtime Pin
Member 16603853-Feb-05 1:13
Member 16603853-Feb-05 1:13 
GeneralRe: Get system properies at runtime Pin
David Crow3-Feb-05 2:54
David Crow3-Feb-05 2:54 
Generalabt keyboard Pin
Anonymous3-Feb-05 1:13
Anonymous3-Feb-05 1:13 
GeneralRe: abt keyboard Pin
Mike Dimmick3-Feb-05 2:43
Mike Dimmick3-Feb-05 2:43 
QuestionChanging Source IP ? Pin
Adnan5623-Feb-05 0:56
Adnan5623-Feb-05 0:56 
AnswerRe: Changing Source IP ? Pin
Antony M Kancidrowski3-Feb-05 1:13
Antony M Kancidrowski3-Feb-05 1:13 
GeneralApply different themes to single application Pin
ledallam2-Feb-05 23:39
ledallam2-Feb-05 23:39 
GeneralRe: Apply different themes to single application Pin
Antti Keskinen3-Feb-05 4:04
Antti Keskinen3-Feb-05 4:04 
GeneralNon blocking MFC Dll Pin
lmfernandez2-Feb-05 23:38
lmfernandez2-Feb-05 23:38 
GeneralRe: Non blocking MFC Dll Pin
Antony M Kancidrowski3-Feb-05 1:07
Antony M Kancidrowski3-Feb-05 1:07 
GeneralRe: Non blocking MFC Dll Pin
lmfernandez3-Feb-05 2:55
lmfernandez3-Feb-05 2:55 
GeneralRe: Non blocking MFC Dll Pin
Antony M Kancidrowski4-Feb-05 12:05
Antony M Kancidrowski4-Feb-05 12:05 
Generalproblem with Picturebox / windows.h Pin
doneirik2-Feb-05 23:25
doneirik2-Feb-05 23:25 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.