|
You could always try TinyXml and compare the two approaches. That way you'll know which is the best for your situation.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
|
hi...
how to insert into a image file on sql database?
how to convert image file format to binary format?
pls can anyone help me?
paulraj
|
|
|
|
|
gnanapaul wrote: how to convert image file format to binary format?
An image file is already in "binary" format (i.e., it's not plain text).
Have you seen this?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi all
I want to enumerate devices in DirectSound through CreateClassEnumerator for Audio playback devices
I have used CLSID_AudioRendererCategory as CLSID but it gives me audio renderer how can i configure it to 2 sound devices rather than renderers
Can anybody help me, please ?
Jabeen
|
|
|
|
|
|
~Jabeen~ wrote: I want to enumerate devices in DirectSound through CreateClassEnumerator for Audio playback devices
ICreateDevEnum::CreateClassEnumerator is for DirectShow where it works on renderer , In DirectSound u need to enumerate using DirectSoundEnumerate and create ur directsound object for this device using DirectSoundCreate8 passing the GUID obtained while enumerating.
modified on Monday, February 11, 2008 6:06 AM
|
|
|
|
|
Hello everyone,
My question is whether my understanding of the solution to type safe issue in CoCreateInstance is correct. There is type safe issue in CoCreateInstance,
http://msdn2.microsoft.com/en-us/library/ms686615.aspx
STDAPI CoCreateInstance(
REFCLSID rclsid,
LPUNKNOWN pUnkOuter,
DWORD dwClsContext,
REFIID riid,
LPVOID * ppv
);
which means the riid and ppv may not conform to each other, for example, we have a IY* variable pIY and wants to get IZ type interface, CoCreateInstance (rclsid, pUnkOuter, dwClsContext, IID_IZ, &pIY);
To solve this issue, the solution from Inside COM is,
1. Define a template class smart pointer IComPtr<t, iid*="" iid="">, where T is type of interface to wrap, iid is its related interface IID;
2. Define a function in the template class called CreateInstance, the implementation is,
2.1 invoke Release(); // release previous held pointer
2.2 invoke CoCreateInstance (rclsid, pUnkOuter, dwClsContext, *iid, &m_pI); // m_pI the wrapped interface pointer member variable for the smart pointer template class.
I think why the solution works, is because in the creation of the template class, the interface type T and iid is matched (example, through constructor or assignment operator), so when using the internal variable *iid and m_pI to invoke CoCreateInstance, the type always match (Interface ID and Interface type).
Is my understanding correct?
thanks in advance,
George
|
|
|
|
|
George_George wrote: why the solution works
__uuidof - microsoft specifics helps. see the implementation of IComPtr, CComPtr.
George_George wrote: so when using the internal variable *iid and m_pI to invoke CoCreateInstance
yes, and also iid can be derived from m_PI instead, by use of __uuidof(m_PI)
modified on Monday, February 11, 2008 11:58 PM
|
|
|
|
|
Not sure I really understand what you're saying here George 
Anyway COM is typesafe because every interface pointer is an IUnknown pointer. That's what COM is all about. It's always safe to call QueryInterface on any non NULL COM pointer because there's always an IUnknown implementation on the other end which will give you a correct response. Like any rules based system it's technically possible to screw it all up but while everyone follows the rules it should all work smoothly.
See here [^] for example.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Matthew Faithfull wrote: Not sure I really understand what you're saying here George
STDAPI CoCreateInstance(
REFCLSID rclsid,
LPUNKNOWN pUnkOuter,
DWORD dwClsContext,
REFIID riid,
LPVOID * ppv
);
REFIID riid and LPVOID * ppv is not safely restricted that ppv will point to interface that relates to riid as LPVOID can take any pointer
Matthew Faithfull wrote: Anyway COM is typesafe because every interface pointer is an IUnknown pointer
This is not known to LPVOID * ppv of CoCreateInstance
|
|
|
|
|
Rajkumar R wrote: restricted that ppv will point to interface that relates to riid
Yes it will, every interface relates to IUnknown, whatever riid is requested. That's the point, type safety comes through QueryInterface on the returned pointer which is always valid to call (except for NULL pointer) and must always return the correct result. i.e. if you call QueryInterface on the same interface you've already got it must succeed and give you a valid pointer. Thems the rules 
Remember you're passing in the address of a void pointer which will be overwritten by the CoCreateInstance call with an IUnknown pointer. If the HRESULT returned is S_OK then you know *ppv is now of type IUnknown.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
May be ur not getting me or I explain not clearly.
Type safety is not what u have meant, please refer [^]
say, int function(int *) expects int * while int function (void *) is undefined.
that is why strongly typed languages uses type system
definition of void in msdn
The void type describes an empty set of values. No variable of type void can be specified — it is used primarily to declare functions that return no values or to declare generic pointers to untyped or arbitrarily typed data.
CoCreateInstance return pointer to IUnknown, but it is not type restricted to store in pointer to int. Actually to tackle this situation using C++ template is what george discussing with the use of IComPtr.
Matthew Faithfull wrote: hich will be overwritten by the CoCreateInstance call with an IUnknown pointer
not necessary. a pointer to object derived from IUnknown not pointer to IUnknown.
both r different. as a side note COM is binary standard it is not restricting to derive from IUnknown.
Question is not related to what CoCreateInstance returns, but is it type safe,
IX *pIX = NULL;
CoCreateInstance(..., IID_IY, &pIX); // not type safe, programming mistake not caught by typesafe compiler.
here trying to get interface to IX, but IID for IY, if COM interface for IY exist then expected IX interface is not valid.
modified on Monday, February 11, 2008 8:51 AM
|
|
|
|
|
I understand void pointers and the concept of type safety but it is not a problem in this case as long as the server obeys the rules of COM it cannot cause a well written client a problem. The traditional problem with returning a void* ( you can't be sure what it really points to ) is removed because it always points to IUnknown.
The only way the client can screw things up is to pass the address of something that sould not be overwritten in the ppv parameter and that would be plain stupid and no fault of the server or the function spec of CoCreateInstance. Your example may be incorrect sematically but it will compile and work there is no type safety issue.
Consider typeof (&(int*)) == typeof(&(SComeInterface)). Or in English, an address is and address is an address as long as we all agree we're talking 32bit addresses.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Matthew Faithfull wrote: I understand void pointers and the concept of type safety
ohh, my explaination is ok i think
Matthew Faithfull wrote: in this case as long as the server obeys the rules
with the context of type safe, here who talks about the COM Server, COM Client Sample is given in george's post. And generally if no body makes mistake with data type handling, type system (int, float, ...) and a strongly typed languages is not required.
Matthew Faithfull wrote: Or in English, an address is and address is an address as long as we all agree we're talking 32bit addresses.
yes, sure address is address, But calling interface function of IX with IX * with the address of IY * is not valid.
Matthew Faithfull wrote: Your example may be incorrect sematically but it will compile and work there is no type safety issue.
to reduce semantically incorrect situation, type safety comes into picture. That is; it won't compile, if you pass IY * in place of IX *.
|
|
|
|
|
COM has to be general, it provides a binary standard available also to languages that are no strong typed.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
please make of use of Strong typed feature of language, which supports it.
|
|
|
|
|
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
I mean not while implementing COM, while using it in a strong typed language.
|
|
|
|
|
And what was your advice about?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
not advice, suggestion
|
|
|
|
|
And your suggestion  was?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Rajkumar R wrote: But calling interface function of IX with IX * with the address of IY * is not valid.
It is when both are gaurenteed to be derived from IUnknown and by the rules of COM you can only call the members of IUnknown until you have queired the validity of the interface you really want by calling QueryInterface. A properly written client will not call any method other than IUnknown methods until it has a result from QueryInterface so you can go right ahead and use your IX* or IY*, when you QueryInterface for the interface you actaully want the COM server can say NO, then it is invalid to make the call you want. The address of IX* and the address of IY* are interchangable up to this point, they are both treated as type IUnknown** regardless and this does not cause any issues other than possible programmer confusion. It is type correct as far as any machine can possibly tell.
Rajkumar R wrote: it won't compile, if you pass IY * in place of IX *.
If the compiler did that then it would not let you pass a CMyDocument* to a function taking a CDocument* that only operates on CObject members and that would make life very difficult
You might want to research into the Ada language if you want to live with those sort of restrictions.
Nothing is exactly what it seems but everything with seems can be unpicked.
modified on Monday, February 11, 2008 9:39 AM
|
|
|
|
|
Matthew Faithfull wrote: The address of IX* and the address of IY* are interchangable up to this point
COM needs QueryInterface basically address of IX and IY may not be the same.
Matthew Faithfull wrote: CMyDocument* to a function taking a CDocument*
but compilers says error when CMyDocument2 * is passed to a function taking CMyDocument1 * ,even both derived one level from CMyDocument.
And also, if the function is taking CDocument, it is expected that the function is expected to work on CDocument interfaces only even though it is the object of CMyDocument, So I think life is not difficult. Even if it needs to operate on CMyDocument, C++ provides typesafe dynamic_cast.
modified on Monday, February 11, 2008 10:13 AM
|
|
|
|
|
Rajkumar R wrote: address of IX and IY may not be the same.
It doesn't matter, as long as both are valid 4 byte parameters an address is an address is an address.
Rajkumar R wrote: but compilers says error when CMyDocument2 * is passed to a function taking CMyDocument1 * ,even both derived one level from CMyDocument.
Not if the function takes CMyDocument*, which is the case we're dealing with here.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
