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
Related
My question is about sinking COM events from a sub object properly, without creating a circular reference that would lead to memory leak(s).
There is an ActiveX control called CMyControl. This control creates an instance of an embedded web browser (IWebBrowser2) internally to display some HTML-content.
The web browser exposes an event source called DWebBrowserEvents2 that can deliver some interesting progress updates to CMyControl. Such as DocumentComplete when the HTML document has been fully loaded or when an error occurs etc.
And CMyControl will handle these events with the help of IDispEventSimpleImpl.
The issue I'm facing is that instances of CMyControl do not get destroyed when Release is called.
The direct reason for this is that the reference counter always ends up at 1 instead of 0.
Turns out that IDispEventSimpleImpl is indirectly responsible for this. This makes sense to me because the web browser needs the control's interface to sink the events, so it keeps a reference. Until you call the IDispEventSimpleImpl::DispEventUnadvise method, then the interface gets released.
But when Release gets called on IMyControl, the event source won't get disconnected.
I understand that: there is no reason why it would do that: Release doesn't even know about it.
Stumbled upon this post where they advise (pun intended) to create a custom "sink" object:
https://microsoft.public.vc.atl.narkive.com/4MgGRavd/dispeventadvise-dispeventunadvise-problem
The idea is that the sink object would see the events fired by the web browser first, before passing them on to CMyControl.
For this, an instance of this sink object would be stored inside CMyControl.
The sink object the connects to (and gets referenced by) the browser instead of the CMyControl instance itself. This breaks the circular reference.
Furthermore, the sink object gets passed a pointer to the "mothership" (the CMyControl instance) so it can perform a callback whenever an events occurs.
My question is: is this really how it should be done? isn't there a better/proper way to connect the events?
Kinda new to Realm and I just took over a project which uses Realm. So I of course access in a lot of spots in my app our realm objects. Recently I've noticed that in 3 specific spots we get more and more crashes about Realm objects that have been invalidated or deleted. In all other spots I hardly ever get a crash..even though I do it always the same. So let's say we have a Realm object User *user, I always call user.firstname. In one particular spot I get often a crash so I assume I should check there if it has been invalidated with if(![user isInvalidated]). But why? Or how do I know when I need to check for that?
Or do I need to check it every single time when I access an object? What about if I pass a realm object in an Array to another method -> Do I need to check if after the passage again?
And more over: What do I need to do if it has been invalidated?
Would be glad for any help, this whole topic seems quite confusing
I was wondering if there is a way to share an NSManagedObject between two or more NSManagedObjectContext objects running in the same thread.
I have the following problem: I have one main context shared through all my code in the application and several different contexts that are created for each remote fetch request that I issue. (I created a custom class that fetches remotely and inserts all the objects found in the server in his own NSManagedObjectContext). Those fetch requests may run simultaneously since they use NSURLConnection objects that may end at different times. If the same remote object gets fetched by different connections, I will end up with duplicates at the moment of saving and merging the context with the main one. (That is, objects that have the same remote ID but a different objectID).
One possible solution would be to save (and so persist) every object as soon as it is created but I can't do that because it may have some relationships that may still have not been filled and won't validate during the save operation.
I'm really looking forward to a method that allows you to share the same non-persistent instance of an object between context. If anybody has encountered this issue and came up with a solution, I would be pleased to know!
Context cannot communicate between each other save through their stores. However, you can insert a managed object with a nil managed object context and it will be independent (albeit without relationships) of any context. You could pass that independent managed object around however you wished and insert it into a context when you needed to persist it. This is dangerous but possible.
However, if you're not running each connection on a separate thread then you don't gain anything by having multiple context. Each connection object will activate its delegate in sequence on the main thread. In this case, your easiest solution would be to use the same delegate for all the connections and let the delegate handle the insertions into a single context. To prevent duplication, just do a fetch on the remoteID and see if you get back an extant object before inserting a new object for that remoteID.
I don't think what you want to do is possible. I mean if you want to share changes between different contexts, you got to use notifications and merge it whenever did save or did change occur. But in your case, I'd say just use 1 context and save in the end. Or a less elegant way: save all the remote ids temporary in your app and check before inserting new ones. In this case, you can continue use multiple contexts and save after each didfinishloading.
I have some trouble with a core data project. I have a NSArrayController with NSManagedObjects in it, and + / - buttons. If i delete a object in the row after the file has been saved it works perfectly, but if I add a new object, and immediately delete it again (without changing any of the default values), i get an error:
Serious application error. Exception was caught during Core Data change processing: Unknown number type or nil passed to arithmetic function expression. with userInfo (null)
Unknown number type or nil passed to arithmetic function expression.
It's the same case if i undo the add of the new object.
Anybody able to give me a pointer what to do? I assume it has something to do with that it only has an temporary ID, but how to solve it i don't know.
I found the problem and solution. For the record i will describe it.
The problem was that the object in its init function added an observer on itself. This was probably what triggered the error. If i before i delete the object remove itself as observer, the error is not produced.
Tables don't usually contain NSManagedObjects. Rather, either an NSArrayController is providing the managed objects' attributes as values via bindings or an object conforming NSTableViewDataSource is. The deletion of a selected object provided in either of these scenarios can be done a myriad of ways. The problem is, you haven't explained at all how your case is set up.
Is it possible your deletion (whatever target/action your button is wired to) is being passed nil or something unexpected? I can imagine a similarly-frighenting error if you asked a managed object context to delete a float value or some other random thing ...
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.