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.
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?
I have a requirement in hand where I need to change the Mule Flow Threading Behavior at runtime without the need of bouncing the whole Mule Container. I figured out few different ways to achieve this, but none of them are working.
I tried accessing the Mule Context Registry and from there I was trying to do a lookup of "FlowConstructLifecycleManager" Object so that I can tap in there and access the threading profile of the object and reset those values, then stop and start the flow programmatically in order to get the change applied in the flow. I am stuck in this approach as I was unable to get hold of the FlowConstructLifecycleManager Object neither from the Mule Spring Registry nor from the Transient Registry. I was able to get hold of the Flow object though which has a direct reference to that FlowConstructLifecycleManager Object. But, unfortunately, they made this object as protected and didn't expose any method for us to access this object.
Since I was unable to access this FlowConstructLifecycleManager directly from Mule implemented Flow class, I decided to extend this Flow class and just add another public method to it so that I can access FlowConstructLifecycleManager object from Flow object programmatically. But, I am stuck in this approach as well as even if I am putting my version of the same Flow class packaged and dropped in lib/user folder of the container, it is still not picking up my version of the class, and loading the original version instead.
It would be of great help if I can get any pointer on the approach of solving either my first or second problem.
Thanks in advance,
Ananya
In our company, we are building a dashboard from where we should be able to start/stop any flow or change the processing power of any flow by increasing/ decreasing the active threads for a flow or changing the pollen polling frequency. All of these should be done at runtime without any server downtime.
Anyway, I made it working finally. I had to patch up the mule-core jar and expose few objects so that I can get to the thread profile object and tweak the values at runtime and stop/ start the flow to reflect the changes to take effect. I know this is little bit messy and but it works.
Thanks,
Ananya
I'm using LINQPad (2.42) to test some snippets that make use of SharePoint Client Object Model.
Basically messing with SPSite, SPWeb, SPList, SPFolder and SPFile.
The problem is that LINQPad seems to dislike calling .Dump() for any of the previous objects. It just keeps "Executing" for ever without showing any results.
Does anyone experience the same problem? Any workaround or fix?
Thanks
Try calling .Dump(0) to only dump the first level of Properties, or dumping the results to a Grid.
I have not looked at the SharePoint Client Objects but if they are anything like the TFS API classes, some of the properties are lazy loaded. Calling .Dump() will walk it's way down each every single result making server calls for every property (and property of property, etc.). This is probably what's taking the time.
Two views in my application need to load same information when restoring state. My idea was, to avoid saving it twice, to have one view create another in init orcreatePartControl if it wasn't created yet. However,
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().showView(...)
doesn't work there, as getActivePage() returns null. Is it possible to work around this?
Delegate to a manager or service to load/maintain/save the shared state. That will ensure the first access initializes your information. When the view is instantiated just go to the manager and retrieve the information. If the user never instantiates your view, then you never had to do the extra work.
In the general case, you can't create/instantiate one view while creating/activating another view. Eclipse won't allow it, and will generate ERRORs in the error log.
EDIT:
3 standard persistence patterns I've seen used (and/or misused :-) are:
1) Have your plugin get its state location and simply serialize you state out there. (location provided for free if you subclass org.eclipse.core.runtime.Plugin) You can do it in your activator stop(BundleContext) method. You can uses classes like org.eclipse.ui.XMLMemento to serialize to/from XML if you don't already have a solution.
2) if you subclass org.eclipse.ui.plugin.AbstractUIPlugin you can use org.eclipse.ui.plugin.AbstractUIPlugin.getDialogSettings() to store your state. Potentially a little bulky as you would have to keep it up to date.
3) have your common manager update a preference, potentially using another serialization technique.
I'm working on a small application using C++/wxWidgets, where several parts of the GUI need to be updated based on e.g. received UDP datagrams. More specifically, a secondary thread tries to keep a list of available "clients" in the network (which may come and go away) and e.g. corresponding comboboxes in the UI need to be updated to reflect the changes.
The documentation mentions that for this kind of thing EVT_UPDATE_UI would be a good choice. As far as I can understand from the sparse documentation, this event is sent automatically by the system and provides some support for assisted UI change.
However, I'd feel more comfortable using a more direct approach, i.e. where e.g. a window object could register/subscribe to receive notifications (either events or callbacks) upon particular events and another part of the code is sending out these notifications when required. I could do this in C++ using my own code, however I guess if wxWidgets already supports something like that, I should make use of it. However I haven't found anything in that regards.
So, the question is: does wxWidgets support this kind of notification system (or similar alternatives) or would I be best served coding my own?
AFAIK there is nothing directly usable in wxWidgets, but doing it on your own seems easy.
What I would do:
Create a wxEvtHandler-descendent class to hold the list of available "clients" in the network. Let this class have a wxCriticalSection, and use a wxCriticalSectionLocker for that in all methods that add or delete "clients".
Create a worker thread class by inheriting wxThread to handle your UDP datagrams, using blocking calls. The thread should directly call methods of the client list object whenever a client has to be added or removed. In these methods update the list of clients, and ::wxPostEvent() an event to itself (this will execute the whole notification calls in the main GUI thread).
Handle the event in the client list class, and notify all listeners that the list of clients has changed. The observer pattern seems to me a good fit. You could either call a method of all registered listeners directly, or send a wxCommandEvent to them.
Have you tried calling Update() on the widget(s) that change? Once you update the contents of the combo box, call Update(), and the contents should update.