When I call the Release method for my Direct3D9 device it returns S_FALSE but I can't find anything that explains why this value would be returned.
From what I can gather, S_FALSE means that it has succeeded but hasn't had to do anything but I only release once.
I also don't think the method does succeed as I am left with a fullscreen DirectX window even after the window has been destroyed and the device released.
IUnknown::Release does not return a HRESULT as you assumed, it instead returns a ULONG indicating outstanding reference count (of this COM object).
Related
I have extended an API in C++ written on a legacy framework that is used via JavaScript/VB. There is an object that can create from another object. However, the coder can hold on to that object (it's exposed) and do operations on it. Also, the object can be deleted. Because of that last part, I need to keep the object around, even when it is deleted in case the developer tries to reference through that object, and if they attempt to do so, return an error (HRESULT), otherwise, it could cause a crash.
What is the best common HRESULT that I should use? I can't seem to find one that matches what I want.
The only one that I found the winerr.h file that might be relivant is ERROR_FLT_DELETING_OBJECT, but I don't think it is meant for that.
EDIT
Perhaps I should not use the word delete and replace it with instead detach. The object is to be detached from the main object, but is still lives on till the gc cleans up. However, if the user were to attempt to use this detached object, I want them to wake up to the fact that they have already detached it and that they shouldn't be playing with it any more.
EXAMPLE
var newObj = container.create_newObject();
newObj.doStuff();
container.doStuffWithNewObject(newObject);
container.RemoveObject(newObj);
newObj.doStuff(); // ERROR - see, still have reference and attempting to do stuff.
container.doStuffWithNewObject(newObject); // ERROR
What I am doing is writing a WPF application to work with our device. The application writes some commands to the device and reads command's response from it. I got pinvoke declarations from pinvoke.net website for CreateFile, WriteFile, ReadFile, etc.
I made a function doing following things, CreateFile(with flag FILE_FLAG_OVERLAPPED
) to open device, WriteFile to send command, ReadFile to read response, WaitForSingleObject and GetOverlappedResult to capture timeout exception if device doesn't respond, and CloseHandle to close device.
This function always worked fine if I called it in UI thread. But I wanted to call it in background thread to keep UI active. So I created a thread in Window_Loaded method(Work is my function's name).
t = new Thread(Work);
t.Start();
Then ReadFile, WaitForSingleObject and GetOverlappedResult group may met error, these three functions returned success and GetOverlappedResult could capture correct read length returned from device. But no actual data read from device filled in the byte array buffer passed to ReadFile function. The failure rate was about 50%.
If I waited thread t to finish, then it always worked fine again.
t = new Thread(Work);
t.Start();
t.join();
Of cause UI would also hang in this situation.
I searched this problem but no exact same question was found. I tried to set background thread's apartment state to STA or MTA explicitly, but it didn't work.
t = new Thread(Work);
t.SetApartmentState(ApartmentState.STA);
t.Start();
It really confuses me. Please help me if you have any idea. Thank you for your reading.
I couldn't find the root cause. But I bypassed it by rewriting read process in C++ function and calling my C++ function with pInvoke.
If I have a code looked like this:
-(void) func {
ObjectA* A = [[ObjectA alloc]init];
[something doSomething:blah andDelegate: A];
}
Assuming the call of doSomething will make a http request call so the delegate will be called only when it received response from the server. In this case, there would be a delay.
Note: something is an instance variable of a class.
If I call 'func' twice, will the first initialized of A be leaked before it received the response on the delegate. Assuming there is a release operation when calling the delegate function when received the responsed.
The reason I thinking of this is because if second initialized of 'A' passed in to something as an delegate before the first delegate finished it's role. Will second initialized of 'A' replaced the first initialized of 'A'?
Yes, if you're not compiling with ARC, you have a leak. You're creating an object with alloc, which means that you own it, and you're not relinquishing that ownership by sending release. This is the core memory management rule for Cocoa.
It may be that the object, something, to which you're passing A, also needs to own A (in fact, it sounds like that is the case). If so, something should send retain to A and then send release when it no longer needs A.
Will second initialized of 'A' replaced the first initialized of 'A'?
Sort of. The name A is only valid inside this method. When you create an object and assign it to A, and then that name goes out of scope, you can't refer to the object anymore. That's what a leak is. When you run this method again, essentially a new name A is created and you assign another object to it.
something and func should be releasing A. something should also retain A when its used.
Why would a process want to call DuplicateHandle from the Win32API, and get it from another process instead of just acquiring the handle on some object itself?
Is there some advantage to calling DuplicateHandle or something?
You may find the answer in Chapter 6.8 of 'Programming Applications for Microsoft Windows'.
Gaining a Sense of One's Own Identity
Sometimes you might need to acquire a real handle to a thread instead of a pseudo-handle. By "real," I mean a handle that unambiguously identifies a unique thread. Examine the following code:
DWORD WINAPI ParentThread(PVOID pvParam) {
HANDLE hThreadParent = GetCurrentThread();
CreateThread(NULL, 0, ChildThread, (PVOID) hThreadParent, 0, NULL);
// Function continues...
}
DWORD WINAPI ChildThread(PVOID pvParam) {
HANDLE hThreadParent = (HANDLE) pvParam;
FILETIME ftCreationTime, ftExitTime, ftKernelTime, ftUserTime;
GetThreadTimes(hThreadParent,
&ftCreationTime, &ftExitTime, &ftKernelTime, &ftUserTime);
// Function continues...
}
Can you see the problem with this code fragment? The idea is to have the parent thread pass to the child thread a thread handle that identifies the parent thread. However, the parent thread passes a pseudo-handle, not a real handle. When the child thread begins executing, it passes the pseudo-handle to the GetThreadTimes function, which causes the child thread to get its own CPU times, not the parent thread's CPU times. This happens because a thread pseudo-handle is a handle to the current thread— that is, a handle to whichever thread is making the function call.
To fix this code, we must turn the pseudo-handle into a real handle. The DuplicateHandle function (discussed in Chapter 3) can do this transformation
One possible use of DuplicateHandle is to duplicate a handle between a 32-bit process and a 64-bit process.
Note: cannot be used on I/O Completion ports or Sockets.
Another use of DuplicateHandle is to open a file in multiple processes when the file uses FileOptions.DeleteOnClose. (such a file cannot be opened by multiple processes if the file path is used to open the file)
See my answer at https://stackoverflow.com/a/36606283/2221472
See here on the MSDN what it has to say about the usage of 'DuplicateHandle'. The best way I can think of it is this way, an analogy if you like - suppose you open a file using the CreateHandle routine for writing only, then you call DuplicateHandle to pass the handle onto another thread in which the thread will read from the file, only the handle is duplicated hence the thread does not have to call CreateHandle again...
Here is a question about IMFActivate::ActivateObject and IMFActivate::ShutdownObject in Media Foundation.
According to MSDN, the component that calls ActivateObject is responsible for calling ShutdownObject.
But there are two examples not following this rule:
http://msdn.microsoft.com/en-us/library/dd388503%28VS.85%29.aspx
and
http://msdn.microsoft.com/en-us/library/dd317912%28VS.85%29.aspx
In these two examples, they call ActivateObject and then release IMFActivate interface without calling ShutdownObject method.
This is going to lead to memory leaking, right? Or there is another way to release the resource occupied by the object?
(Can I use IMFMediaSource::Shutdown to release the object instead of using IMFActivate::ShutdownObject)
Thanks in advance.
You're right that you're supposed to call IMFActivate::ShutdownObject when you're done using the object you activated. However, notice that the sample in question is instantiating an IMFMediaSource to be returned in an out param.
HRESULT CreateVideoDeviceSource(IMFMediaSource **ppSource)
If CreateVideoDeviceSource were to do a ShutdownObject on the IMFMediaSource it instantiated and then hand it back to you, it would be in a shut-down state and therefore probably unusable.
To answer your question about what you're supposed to do about this, you can probably get away with a pMyMediaSource->Shutdown() after you're all done using it.
More info: IMFActivate's other use in Media Foundation is for allowing an MF object to be instantiated in a different process (useful because the MF Media Session will play DRM-protected content in a separate process); in that case, the MF Media Session will indeed call IMFActivate::ShutdownObject on any IMFActivates you gave it.