I have a WPF app that uses a non-WPF vendor library. My app does not receive any events that the library fires. I've been told that this is because I need a message pump.
In another (very similar) question, the accepted answer suggested using System.Windows.Threading.Dispatcher.Run().
When I add in that call, however, my window won't pop up-- the app is effectively backgrounded and I have to shut it down with Task Manager.
I'm really stumped here, and I'm not even sure how to investigate it. Any help would be greatly appreciated.
You already have one if you use WPF, there's no other way that it can get any Windows notifications. Every WPF app starts life with a call to Application.Run() on the main thread. It is usually well hidden, auto-generated in the bin\debug\app.g.cs source code file. Application.Run() in turn calls Dispatcher.Run()
Your vendor is correct, without a message loop many COM components go catatonic. But since you have one you need to look for the problem elsewhere. Don't use the component on threads.
Related
I have a running WIN32 application. There a window in this application where I want to show web content using CEF3. But, I am facing problems and the entire window becomes white without showing any web page content. So I have the following questions:
Is it possible to use CEF3 with existing message loop in application? I dont want to call the CEF message loop, it may impact other things in my application.
Is it absolutely necessary to use a message window as in the sample application? I am not able to understand its objective.
When CEF3 launches multiple processes, how does it show in the task manager? If my application name is A.exe, does it show A.exe multiple times in task manager?
Any help is much appreciated.
For windows users there is possible to use multi threaded message loop (CefSettings). It is allow maintain browser windows via own message loop. But there is good practice use single threaded message loop, - you can call CefDoMessageLoopWork periodiacally on idle or some additional events. It is possible even with existing message loop.
I'm not sure what you mean.
CefSettings.BrowserSubprocessPath specifies which executable will be used for child processes. While you are integrating it in other process, looks like it is one possible solution and in task manager you will see processes as you named it.
About the question number 2:
every windows application has its own "main window" and wndProc that receives all the messages sent by his children.
And the sample win32 cefclient shows how to integrate cef message loop inside the application's message loop.
And if you don't handle and dispatch cef messages in proper way the browser window becomes white.
This scenario has come up before and I'm wondering if there is any way I can determine where the actively running form is executing within code? The problem is when I inherit a very large application which I'm not totally familiar with yet and I have it running through VS.NET 2010. I might have a particular screen up and go "geeze it would be nice if I could start debugging when I do 'x'".
If this was a simple form with some buttons I wouldn't even bother asking here; I'm not that novice. But the time consuming task is when I look at a tabbed screen in a large multi-project solution with drag and drop capabilities, right click options, etc. and have to spend 5-10 minutes tracking down where to place a breakpoint to debug.
What I'm wondering is if there is a way to have the WinForms app running via IDE and do 'something' that tells VS.NET on the next action break into the code (obviously without a breakpoint because I don't know where to place one yet). This would save me a ton of time trying to track down which event is occurring in a not so simple form or series of forms.
I hope this makes sense...
Thanks!
Yes, that's somewhat possible. When you use Debug + Break All then the 99.9% odds are that you don't break into code that's part of the project. A Winforms app is normally idle, pumping the message loop and waiting for Windows to tell it that something happened. You'll break at the Application.Run() statement.
The trick to then use Debug + Step Over. The program resumes running like normal. Then give a UI command (do 'x' in your question) and the debugger will break at the first statement of real code, typically at the start of the event handler for that command. It isn't exactly guaranteed that that code would be relevant, you might break at a MouseMove event handler for example. So YMMV.
The app is using my library which works using threads to do some operation; also it uses SIP VOIP library (obviously it is using threads). GUI is bound to interfaces of both libraries.
I noticed a weird behavior of my app. Usually it works just fine but sometimes after some time (3-5 minutes) it suddenly closes.
It is too irregular to debug it or diagnose.
Anyone had that kind of problem? Any idea what could be the reason for that?
I would recommend you add an application level error handler so that you can log any errors that are occuring that you might be missing. It is as simple as
Application.Current.DispatcherUnhandledException += HandleApplicationException;
Here is an MSDN article that describes it:
http://msdn.microsoft.com/en-us/library/system.windows.application.dispatcherunhandledexception.aspx
Basically, I have two applications that run sequentially (second is started by the first, and the first exits immediately after.) I'd like to pass ownership of a window the first application created to the second application. The actual contents of the window don't need to be passed along, it's just being drawn in by DirectX.
Alternatively, but less desirably, is it possible to at least disable the window closing/opening animation, so it at least looks like the desired effect is achieved?
(This is in C, using the vanilla Win32 API.)
Instead of separated application make a DLL that will be loaded by the first application and run within it.
I suspect that you're going to run into problems because the WindowProc function is located in the memory address space of the program that you're closing.
Also, a quick look at the second remark at the bottom of the documentation for RegisterClass doesn't seem to offer up much hope.
The only work around that I can suggest for what you've described is to not close the first application until the second application is finished with the window in question.
you can use API hooking to make your DLL capture API windows calls sent by the application window and respond as if your DLL is the windows DLL
for more information about hooking check :
Hooks Overview
I am kind of lost here, and I don't know what to do
I have a problem that I don't know what the source of it.
We have a large wpf application, that is built similar to prism (composite application)
Actually we are using lots of prism library.
I wrote a module to replace an existing module.
And the application now is loading my module, instead of the old module.
I start to notice, with the new module, that sometimes the application freeze for 20-30 seconds without any response, and then it work smoothly after that.
The freeze is not consistent, and there is no pattern or a specific reason that cause it.
I am suspecting that could be my module that is causing that freeze.
But at the same time, many other developers introduced new code to the application.
My question is there a way to trace that freeze?
Is there a way to compare the old module and the new module that I wrote?
I can run the application with my module, and trace the application, and then I can change the config file to load the old module.
Is there a way to compare between the two?
Should I do profiling?
and if profiling will help, then what should I look for?
any other tool could help?
Thanks a lot for any reply
It sounds like you are doing a long running operation on your UI thread. Are you making any database / webservice calls from the main thread? I think one of the easiest things to do is run it in the debugger, and when it freezes, hit the "pause" button. Visual Studio will pause execution at the current location, and you can examine what is taking so long.
If the problem isn't immediately obvious there, I would definitely start profiling the application to track this down.