I create a currTexture of type ID3D11Texture2D via a call to
ID3D11Device->CreateTexture2D(&m_desc, NULL, &currTexture);
What is the proper way to release the resources assigned to this Texture2D? There does not exist a ReleaseTexture2D()-function or something like that…
Thanks! :-)
There does exists a Release method as you can see in the docs:
"The ID3D11Texture2D interface inherits from ID3D11Resource".
"The ID3D11Resource interface inherits from ID3D11DeviceChild".
"The ID3D11DeviceChild interface inherits from the IUnknown interface".
And the IUnknown has method Release.
So call currTexture->Release() when you are done with it.
Related
Sorry if this is a dumb question, but I was wondering if the COM pointer-marshaling functions will work with objects created using ATL's CComCoClass::CreateInstance. According to the docs, that method will "create an instance of a COM object and retrieve an interface pointer without using the COM API." Does that mean its pointer interfaces can't be properly marshaled using COM functions? Thanks for any info.
When you create a COM object using CComCoClass::CreateInstance the object instance will be created in that apartment where your call is executed. Note that the object will be created in unstable state with reference count equal to zero. You should call QueryInterface method for this instance to get the COM interface pointer which can be marshaled to any other apartment.
Please don't close as duplicate. I know there are multiple threads on this topic but none of them answers my question.
I am still struggling to understand why do we need Cloneable interface in java. If we want to create copy of an object, we can simply override clone method from Object class and call super.clone().
Since clone method in Object class is native, we don't know if the native implementation checks for instanceOf Cloneable and then create a copy else throw CloneNotSupportedException.
I know it's not a good practice to override clone() method to create a copy and should go for copy constructor instead, but still I want to know is the existence of Cloneable marker interface justified.
Whether an object implements Cloneable or not only matters if the built-in Object.clone() method is called (probably by some method in your class that calls super.clone()). If the built-in Object.clone() method is called, and the object does not implement Cloneable, it throws a CloneNotSupportedException. You say "we don't know" whether the Object.clone() method does that -- we do -- the documentation for Object.clone() method in the Java class library explicitly promises it, and it describes in detail the cloning operation that the method performs.
If you implement a cloning method that does not call up to Object.clone(), then whether the object implements Cloneable or not has no effect.
I have a signal produced from a module. I want to define a signal listener class in another module but whenever I want to subclass it from CIListener, it says it cannot make a new instance from my subclassed listener because the CIListener class is a pure virtual class (interface class). But I have re-declared or redefined all the pure virtual methods in my listener class. Instead when I user CListener class to subclass my listener it works! Do I have to subclass from CIListener?
I guess you believe that you have re-defined all pure methods, but in fact the compiler thinks otherwise. There are 7 pure virtual methods that should be implemented with the proper signatures. If you want to support only certain data types (as it is in most cases) I would suggest to implement (extend) the cListener as it is just a NOP implementation of the cIListener interface (with all its methods throwing a datatype not supported error). Be sure to see whether you indeed override the necessary methods. You may use the override C++ keyword in your method definition.
i'm faced with implementing an IDispatch interface. There are four methods, and fortunately 3 of them are easy:
function TIEEventsSink.GetTypeInfoCount(...): HResult;
{
Result := E_NOTIMPL;
}
function TIEEventsSink.GetTypeInfo(...): HResult;
{
Result := E_NOTIMPL;
}
function TIEEventsSink.GetIDsOfNames(...): HResult;
{
Result := E_NOTIMPL;
}
It's the last method, Invoke that is difficult. Here i am faced with having to actually case the DispID, and call my appropriate method; unmarhsalling parameters from a variant array.
function Invoke(
dispIdMember: DISPID;
riid: REFIID;
lcid: LCID;
wFlags: WORD;
var pDispParams: DISPPARAMS;
var pVarResult: VARIANT;
var pExcepInfo: EXCEPINFO;
var puArgErr: DWORD
): HRESULT;
Not wanting to have to write all the tedious boilerplate code, that i'm sure will have bugs, i went googling - rather than doing any work.
i found this snippit on the MSDN Documentation of IDispatch.Invoke:
Generally, you should not implement Invoke directly.
Excellent! i didn't want to implement it anyway! Continuing reading:
Instead, use the dispatch interface to create functions CreateStdDispatch and DispInvoke. For details, refer to CreateStdDispatch, DispInvoke, Creating the IDispatch Interface and Exposing ActiveX Objects.
The Creating the IDispatch Interface link says:
You can implement IDispatch by any of the following means:
[snip]
Calling the CreateStdDispatch function. This approach is the simplest, but it does not provide for rich error handling or multiple national languages.
[snip]
Excellent, CreateStdDispatch it is:
Creates a standard implementation of the IDispatch interface through a single function call. This simplifies exposing objects through Automation.
HRESULT CreateStdDispatch(
IUnknown FAR* punkOuter,
void FAR* pvThis,
ITypeInfo FAR* ptinfo,
IUnknown FAR* FAR* ppunkStdDisp
);
i was going to call it as:
CreateStdDispatch(
myUnk, //Pointer to the object's IUnknown implementation.
anotherObject, //Pointer to the object to expose.
nil //Pointer to the type information that describes the exposed object (i has no type info)
dispInterface //the IUnknown of the object that implements IDispatch for me
);
What i cannot figure out is how the Windows API implemention of CreateStdDispatch knows what methods to call on my object - especially since CreateStdDispatch doesn't know what object-oriented language i'm using, or its calling conventions.
How will CreateStdDispatch know
what method to call for a given dispid?
the calling convention of my language?
how to handle exceptions from the language that my object oriented object is written in?
Note: i have no choice but to implement a dispinterface; i didn't define the interface. i wish it was a simple early bound IUnknown, but it tisn't.
Doesn't the ITypeInfo parameter passed into CreateStdDispatch expose all of the method information?
So you'd create type info first calling CreateDispTypeInfo and pass that through to CreateStdDispatch which can then use the type information to work out which method to call since CreateDispTypeInfo requires INTERFACEDATA which contains all this information
I could be way wrong since I don't have time to look into it but that would make sense to me.
I'll investigate this later and update the answer.
The short answer to your question is: neither CreateStdDispatch() nor the IDispatch implementation it creates knows anything at all about the methods to be called.
The object that you get back simply stores the parameters that you passed to CreateStdDispatch(), and for all IDispatch methods it only turns around and makes the corresponding calls on the ITypeInfo that you gave it. That is all.
If you pass nil for ptinfo as shown in your code then you only get E_INVALIDARG, since the implementing object cannot do anything at all without an ITypeInfo to which to delegate all the work.
If you inspect the code for CStdDisp in oleaut32.dll then you will find that it calls API functions like DispInvoke() (which also live in that DLL) instead of invoking the ITypeInfo methods directly, but these functions are all simple wrappers for calls to the ITypeInfo methods, without any further functionality.
In case anyone wonders: neither CreateStdDispatch() nor CStdDisp performs any additional magic; all they do is give you an IDispatch that does whatever the ITypeInfo that you passed in can do. Think of it as a kind of an adapter that allows you to plug an ITypeInfo into an IDispatch socket.
It is true that TAutoIntfObject.Create() needs a type library. However, all that the constructor does is call GetTypeInfoOfGuid() on it in order to get a type info pointer, to which the object then delegates most of the work related to dispatch things.
Borland in their wisdom made the member variable for the type info pointer private, which means that you really need to hand the constructor some type library or other that contains the interface in question, instead of simply writing another constructor or overriding some virtual function. On the other hand it shouldn't be too hard to load the type library via the registry or to dump parts of it to a TLB file. Inspecting a TLB with OleView gives you actual compilable IDL which is often also Borland-compilable RIDL.
CreateStdDispatch() does not know anything about exceptions either. The catching of exceptions thrown from COM methods and their conversion to HRESULT and/or IErrorInfo is compiler magic induced by Delphi's safecall keyword on the implementing method.
The same goes for the translation of HRESULTs to exceptions when calling COM methods specified as safecall in their interface declarations. The compiler simply inserts a call to #CheckAutoResult after every invocation of a safecall method; this function checks the HRESULT and throws EOleSysError if appropriate.
Simply switch the Delphi debugger to disassembly ('CPU view') to inspect all the magic that the compiler does for you!
Whenever I put my component into COM+ and call CoCreateInstance() on the client the following happens:
the runtime instantiates the object (calls IClassFactory::CreateInstance())
the runtime calls QueryInterface() for the interface specified in the CoCreateInstance() call
the runtime calls QueryInterface() for IdentityUnmarshal interface ({0000001b-0000-0000-c000-000000000046})
The only thing I can find is the declaration in comdef.h that there exists IdentityUnmarshal interface with that interface id.
ComDef.h:
class __declspec(uuid("0000001b-0000-0000-c000-000000000046")) IdentityUnmarshal;
Is there any more information on it?
If I remember it correctly you may query for IdentityUnmarshal interface to define if you are dealing with proxy or not. If result is S_OK, then Proxy.
Update: check out this discussion