Is there any benefit of using COINIT_MULTITHREADED in a DirectShow application? For now it has given me some troubles, but I am not sure if using CoInitializeEx(NULL, COINIT_APARTMENTTHREADED) is the right fix for the problems.
The full story:
I have a pretty straightforward web camera capture application with ability to choose the capture source and call the device manufacturer settings through OleCreatePropertyFrame.
My app runs pretty stable, no memory leaks, I can switch between devices without any problems (I completely rebuild DirectShow graph each time when user chooses device).
But there is only one problem after showing the property page of the capture filter. If I just show it and close without changing anything, all continues normally. If I change any setting in the property pages and then close the property frame, also everything continues seemingly normal .. until the next time I change the device and rebuild the graph. The previous graph gets destroyed normally, no errors, filters are being removed and released correctly. And right when I create a new graph and call graphBuilder->SetFiltergraph( pfg ), my app crashes with some weird access violation errors insde of Kernel32. But if I change COINIT_MULTITHREADED to COINIT_APARTMENTTHREADED, this error disappears.
So is that COINIT_MULTITHREADED a real problem of my application or maybe there is some other monster hiding somwhere? Has someone experince with it?
Any thread that creates a window must be STA. Both user32 and gdi are fundamentally thread-unsafe.
Related
I am making a vim-style "window manager" that takes text input, much like Alfred or Spotlight in Mavericks (in a floating panel).
The problem I'm having is when I call activateWithOptions: on a running application it steals focus from my window. I was hoping the problem would be solved by simply bring my app to the foreground again, however it seems the activation is running on a separate thread, and I end up activating my app before the original app gets activated.
I have tried reactivating when I receive NSWorkspaceDidActivateApplicationNotification, but that doesn't work either.
Ideally I'd like to pause execution until the application is focused for multiple reasons, since that would be the window I manipulate further.
Does anyone have any suggestions?
I am creating an app for Window 8 using the 'Windows Runtime'.
I have a custom control which does it's own painting. To accomplish this, I am using a Rectangle control and setting it's 'Fill' property to an ImageBrush derived from a SurfaceImageSource and then using an ID2D1RenderTarget to do the painting. For painting bitmaps I am using ID2D1RenderTarget::CreateBitmapFromWicBitmap and am saving the ID2D1Bitmap that is returned. The control is animated and I create and all of the bitmaps that I need and then continuously paint the scene.
This all works well for the most part. However I am finding that on a random basis, suddenly all of the ID2D1Bitmaps that I have squirreled away stop painting anything. I can trace through the code, and there seems to be nothing wrong, but when I call ID2D1RenderTarget::DrawBitmap, nothing happens. I find, however, that if I force the ID2D1Bitmap to be recreated from the file, it then works fine again. It is almost as if the bitmap has been invalidated or something.
This loss of the bitmaps happens very infrequently and appears to be random, but I can pretty much guarantee that it will fail within an hour or so of playing. I am pretty sure that it is not a memory leak because I can run the app for hours at a time without any increase in memory used. Also, if I force the bitmaps to reload, I can then continue on as if nothing had happened.
Can anyone give me a clue as to what might be going on here?
Thanks.
After much trial and error (not helped by the fact that it was VERY difficult to reproduce the problem), I discovered that the root of the problem was that the call to ID2DRenderTarget::BeginDraw was returning DXGI_ERROR_DEVICE_REMOVED. In the example code upon which I based my code, it showed that in response to this error, I needed to re-create the context, which I was doing. However I was not deleting all of the cached bitmaps associated with the old context, and those bitmaps would not work with the new context. I fixed that and now my app recovers from this error.
Although this solves the problem, I am still not sure I understand why I am getting the 'Device Removed' errors at random times while playing. Also, needless to say, that reloading all of the graphics in the middle of playing shows up as a nasty delay glitch. Fortunately it happens rarely, so I guess I will have to live with it.
I have some code in Form Load event. It is doing fine. But when it reaches to pick data from database, no commands are executing after that. There is no error at all but it just goes silent.
I tested it as follows:
MsgBox("1")
vrStudentName = DsGetPprStatusfromEnrSummary.tblPaperEnrSummary.Rows(0).Item("StudentName")
MsgBox("2")
Please advise.
Thanks
Furqan
Message Box one is showing data but not the message box two. In fact, the second message box statement is not showing any response at all.
This is a nasty problem on 64-bit operating systems. Any exception raised in code that's run from a form's Load event is swallowed without a diagnostic. This is an old problem that is not getting solved because the DevDiv and the Windows groups at Microsoft are pointing fingers at each other. My finger is pointing at the Windows group but that doesn't help either.
Two basic ways to solve this problem:
Project + Properties, Compile tab, scroll down, Advanced Compile Options, change the Target CPU option from x86 to AnyCPU. This disables the Wow64 emulation layer that swallows the exception.
Debug + Exceptions, tick the Thrown box for "Common Language Runtime Exceptions". The debugger stops as soon as the exception is thrown.
Also keep in mind that it is very rarely necessary to use the OnLoad method or Load event. Only code that requires the Size or Location or Handle of the form to be accurate needs it. Anything else belongs in the constructor of the form. That Load is used so often is a VB6 anachronism, carried over in the designer design which made the Load event the default event for a Form. Add a constructor by typing "Sub New".
Well, it seems pretty obvious that the call to DsGetPprStatusfromEnrSummary.tblPaperEnrSummary is never returning; which means the problem is IN THERE somewhere.
So what on eath is it? I'm guessing it's a DataSet, yes?
But you've referenced it staticly, which is YuckyPooPoo(TM) IMHO, because it's a complex artifact, and you've rendered EVERYTHING which references it unisolatable, and therefore fundamentally untestable!
Received answer on Codeproject
In the dialog that comes up, put a tick in every checkbox under both "Thrown" and "Unhandled". Press OK.
Now, when you run your app though the debugger, it will break for any exception, even if you have an active handler. This should help you track down the problem.
Issue RESOLVED
I'm writing a simple Cocoa Application, no core data or multiple document support. Running on a Mac Pro, OS X 10.6.6, Xcode 3.2.3.
I have reduced my application to the following code in my AppDelegate class:
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
NSOpenPanel *openPanel = [NSOpenPanel openPanel];
[openPanel runModal];
return;
}
From within the debugger, I will run my application. As expected a somewhat not-to-useful OpenPanel will appear. I will click Cancel and it will disappear. All this is as expected. When I click [Command + Q] to Quit the application, the UI will go away but the debugger will indicate that the application is still running (as does the console output).
Based upon all the information I'm reading, I should not have to do anything else in order for this to run right. I've downloaded several examples on the Open Panel's usage but most use the deprecated methods of opening modal giving additional information as parameters. FWIW, I tried those methods and am still seeing the same result.
One last item, when the Open dialog appears, just for an instant I see a message box asking me something to the extent if I want my application to receive incoming connections. The dialog quickly disappears. I don't know if that is part of my problem or not. [Update - this deals with my Firewall being turned on.]
Yes, I'm fairly new at Objective C but not at programming in general. Any words of wisdom is greatly appreciated!
2011.02.07 - Update:
I have walked the debugger line by line without incident. There is no indication of any program failure in the console window.
I say that the debugger is still active after [Command + Q] because the Stop Process toolbar button is still enabled as is the Break button. Further the console indicates that after I tell the application to terminate (either via the menu or key command) that it is still running. The following is the Complete console output from start of run to after I Quit the application.
Program loaded.
run
[Switching to process 62370]
Running...
The Activity Monitor (system tool) will show my application terminating (no longer shows up as a process) but the Debugger will still not transition to "edit" mode - if I tell Xcode to run the debugger again, it will ask me if it's OK to Stop the current debugging session. If I was in Windows I would start looking for background threads keeping the process alive but as far as I know, NSOpenPanel should not be doing something like that.
I have further simplified the program to nothing more than creating a brand new Cocoa application and inserting the code snippet above - no other additions to the template project or updates in any way.
And lastly, when the application is run under the Leaks Performance Tool, everything runs fine when the panel is created but never used. When created and actually used though, at the end of the run I will get the following message in the tool "insufficient task_for_pid privileges (leakagent64)". Googling this hurts. If I read it right, the debugger does not have sufficient permissions to fully kill the target process ??? Now that sounds stupid but ... It does not make sense!
Another update - I just downloaded and ran FunHouse, one of the SDK sample applications that also uses NSOpenPanel. Well don't I feel special. It exhibits the same exact behavior. So from this I conclude either Apple has a bug in their code, my machine is special and messed up, and finally, it is Not my code that is at fault. That being the best part. Tomorrow, I will use a friends Mac and see if the same behavior is exhibited on his box.
This is just too weird.
I rebooted my box, took it to work and found it worked like a charm! I will assume this is fixed and has nothing to do with any other connected devices at home as compared to at work.
If it re-exhibits at home, then it is a network/device issue. Thanks all for your inputs and suggestions! Very much appreciated.
What, specifically, does the debugger say? It's possible that your program crashed, so the debugger is showing you information about the crash.
What if you omit any attempt to run an Open panel?
Within my Cocoa app, I call NSWorkspace's openFile: method to open some file with its default application.
Sometimes this works just fine, and the other application gets focus, as it should.
But alas, sometimes (the occurrence of which seems to be totally random), after the focus goes briefly to the other application, it goes quickly back to my Cocoa app. This is unwanted.
Any ideas what the causes could be?
Note: I have also tried the openFile:withApplication:andDeactivate:, passing YES to the last argument. This doesn't work either. The strange random occurrences of focus going back to my Cocoa app persist.
I'm unable to reproduce this now. Not sure what the problem was.