Develop Reference

Taking screenshots of partially hidden windows from .NET WPF applications

I am working on a program that starts several other c# WPF applications and checks wether there are errors (using .NET Automation Services / UITesting).
One of the requirements of it is to take a screenshot of the main window and to put it into a word document. I alread got it working quite fine when it´s one application at a time (using code from this site: http://www.developerfusion.com/code/4630/capture-a-screen-shot/) , but as soon as i am using parallelism (say, checking 5 applications in a parallel manner), i am running into the problem that the screenshots of the windows may be overlapped by other windows that just popped up or that are always brought to the front (e.g. splash screens). Bringing the window to the front does not really help.
There was an older similar thread not directly regarding to WPF applications, and sadly, without a clear solution: Taking screenshot of a partially hidden window in a programmatic way
Is there a way to get a "clean" screenshot, may be with the use of the windows AutomationElement instance?

WPF application stops interacting on screen rotate

We have a WPF app which runs fine, but a user reported that it locks up when the screen is rotated. (Tablets will do that!)
The app actually renders fully after the rotate but stops responding to the mouse/keyboard. It doesn't show as 'non-responding' in a Windows sense.
We can simulate the "lock up" here, but debugging this is odd:
Lock up does not occur while in VS debugger
If you try and attach to the locked up process, VS says the process was built without debug information
Before the lockup VS can attach/deattach to the same EXE process
We have put trace outputs in global unhandled exceptions but nothing is fired.
I can only think of one next step to debug which is start to hack out chunks of code and find the breaking area.
Anyone seen this before or got any suggestions?
Thanks!

The issue was with an update library we were using called Sparkle.
It was creating a hidden WinForms form in it's constructor. There must be some kind of WPF/WinForms interop bug during screen rotations. Removing that form or removing the library fixed the issue.

How do I profile ShowDialog?

I took over a Keyboard hook project and have been sprucing it up a bit. It used to be just 4 forms that had all the logic and maths in those 4 files. So MANY hours later I just about got the program back together after decoupling everything. The latest bit is by using the Model-View-Presenter design concept on the main window. All my tests work great on my machine, and naturally the program performs like it should on the target computers.
The target computers are simple x86 Intel Atom processors with 2gb of ram. They have buttons on them that correlate to F13-F18 on a keyboard (that is where my keyboard hook program comes into play). My development PC is a semi-stout 6-core AMD x64 machine with 8gb of ram. One thing I wanted to do was test out a way of setting those Function buttons to a particular task. All my unit tests pass for this portion. When I click on a new task type it works as desired.
"Cool", I say, "Lets see it in action" so i hit run in Visual Studio. I my program that F9-F12 are the keys to hook. Now the assignment window only opens up when you press one of the hooked keys when the main window is open. If that main window is not open then the task is performed. So I open my main window and hit F9 and the Assignment window shows but i can't click on anything for about 4 seconds. Then it "catches" up and does what ever I clicked on. I thought maybe it was my debugger so i went to the bin folder and ran the application directly and same deal.
I thought maybe it was a permissions thing so I ran as admin and same problem. I wondered how bad it would be on the target computers. I copied my bin folder to a flash drive, copied the content into Program Files and ran it. It worked great (well to a certain degree) But the problem was not present. I can select any task I want immediatly after the dialog is visible.
One strange thing is though that my keyboard hook stops working after 11 times of trying to reassign it...but that is a separate question. So i thought I remember someone saying, use a profiler. Well my visual studio had one so I turned it on but i can't make heads or tails of the data returned. I'd post code, but I don't know what to post. I even went as far as using System.Console.Write("."); around the area I thought was the problem but that wasn't the problem
protected override void theHook_RegisteredKeyPressed(System.Windows.Forms.Keys key)
{
if (TakeOver)
{
if (!Busy)
{
busy = true;
LibraryTrace.Start("NewKeyAssignment", key);
using (var window = new AssignmentTypePanel())
{
presenter = new TaskPresenter(window, theList[key].Task);
window.Presenter = presenter;
//execution will not continue past here until window is closed
window.ShowDialog();
}
theList[key] = new TaskKey(key, presenter.Task);
LibraryTrace.End("NewKeyAssignment", theList[key].Task.ToString());
busy = false;
}
}
else
{
base.theHook_RegisteredKeyPressed(key);
}
}
So i'm stuck. I can't figure out what to type, what to ask. Any tips on how i can find the root of this problem?

I had a similar problem with an application i developed using winforms- the 'server-side' operation was lightning-quick, but still the form showing the results took ~5 seconds to show.
Upon investigation, it turns out that winforms has some known performance issues.
There are some suggestions for optimization (like here or here and a few others i've found at the time but can't seem to locate right now).
Actually, none of them helped in my case.
I ended up realizing that the real bottleneck was creating and displaying a new form; what I ended up doing was a bit of a hack-
I placed ALL of my controls on the main form, with some of them hidden, and simulated a change of forms by hiding some controls and displaying others.
It's quite ugly, and won't scale up, but worked very well in my case.

silent crash Win7 64bit on ResumeLayout() with winforms and C#

I'm building a Windows Forms application in C#, and testing on Windows 7 64bit revealed a silent crash.
The exact line that it fails on is this.ResumeLayout(false); near the end of the InitializeComponent() function. It's a part of the Visual Studio generated code from the Forms Designer.
There is no exception, no popup to show the program has crashed, nothing. It simply ceases to run once it hits that line. This only occurs in 64bit. Removing that line, the program runs, but cannot be maximized, and there are several other oddities related to window properties.
I've tried everything from changing build settings to using CorFlags.exe, nothing has helped. What could be the issue?
If it makes a difference, I'm using OpenTK and the GL Controls.

Had an identical problem, only in my case the software ran on some 64-bit systems and not others. For example, my laptop is a vaio pcg series bought just this year. 64-bit Windows 7 Home Edition, 1600 x 900 resolution. Program runs just fine here. My colleague has a vaio svz series, 64-bit Windows Professional with 1920 x 1080 resolution, and for some reason his kept getting the silent crash on the ResumeLayout(false) call.
Again, commenting out the this->SuspendLayout() call near the top of the INitializeComponents() sub, and the this->ResumeLayout(false) call near the bottom fixed the problem, and the program seems to run fine on both systems now.

I had the same exact problem with ResumeLayout(). It ran fine on several machines, but I had one user who had it throwing "Exception has been thrown by the target of an invocation." Not very helpful. Unfortunately they also hide some of the details from Exception.StackTrace. I consulted with our resident expert and he felt it was a resizing issue. I discovered exactly where the problem was after going to DEBUG-->Exceptions and selecting everything. I then got a break right inside a function I was using to reposition some checkboxes. For some reason this was throwing an out of range exception on this user's box...
Rectangle rect = dataGridView.GetCellDisplayRectangle(col, row, true);
The point being that selecting the break on exceptions options as I described helped me pinpoint the actual problem. The workaround that others mentioned is fine, but in this case I was able to find the root cause.

Do you use some external component?
Some OCX which is not compatible with 64bit? I had your same trouble using GdPicture.
If so, try to compile for 32bit and problem could be solved.

A simple solution to this whole ordeal was to simply remove both the offending ResumeLayout() call and its corresponding SuspendLayout() call at the beginning of the InitializeComponent() function. It seems to have had no ill effect on the layout of the window despite having a heavy number of controls on the window. Again, this was only for 64 bit machines, the issue never popped up on Windows XP or 7 32 bit.
I'm still baffled as to why the ResumeLayout() call was causing a silent crash in the first place, and still feel slightly uneasy about the "solution", but it seems to have worked.

"Red Cross" problem on MenuStrip and ToolStrip

I have a piece of software that has worked fine on many machines, althoughon one machine there is a problem that appears to occur occasionaly, the MenuStrip and the ToolStrip both appear as a blank white background with a red cross over it, as a custom control would if you created a null object. This doesn't happen whilst I am debugging and I don't know how to make the problem re-occur, but it does happen. I was wondering if anyone knew what could be the problem?
Would it be the version of the .NET framework?
Thanks

This is a common occurrence when there's a GDI+ problem ("The Red X of Death"). Are you doing any custom drawing in OnPaint? Or perhaps there's a graphic resource or a glyph which is corrupt or being improperly disposed of.
Edit: I've re-read your question. You seem to have this only on one of the machines. I've googled around a bit for this, and I stumbled upon this old thread. The post at the bottom suggests that there might be an issue with Virtual Memory turned off:
We did manage to solve this - we were
seeing the problem on a device running
XP embedded. The XPe image developer
had turned off Virtual Memory and as
soon as we turned it on the problem
went away. I believe it is just a
symptom of the system running out of
memory to display the graphics (maybe
particularly if you use a lot of
double buffering)
Hope that helps.

Sounds like a symptom of an Out Of Memory Exception to me.
Edit:
Which can sometimes lead onto a System.InvalidOperationException: BufferedGraphicsContext

Are you trying to update the GUI controls from a thread other than the GUI thread? Combine the cross thread operation with an exception handler that swallowed everything and we had the behavior you describe (on a grid control, not a menustrip bar) on an app I was maintaining.

Definitively sounds like a cross-thread problem.
Make sure you use Invoke when accessing controls and/or firing events from a thread that is not the main UI thread.

Seeing this happen on just one computer of more than a 1000 that have our prouducts.
On that one computer I am seeing a .NET 3.5 program occassionally show the red X on its datagrid. And another far simpler .NET 2.0 program got the red X on its menuStrip. I only have source code for the simpler program but I can say that there isn't any user code at all which affects that component. No cross-thread stuff because nothing updates it. It's contents are set at development time with one item added to it at program load. The Red X failure was well after program load.
I was very surprised to see the problem across two different frameworks and on one program that has no data bindings. I am very wishfully hoping that the computer has its virtual memory turned off.
If it isn't that then any guidance on system parts that are shared across .NET 2.0 and .NET 3.5 would be appreciated.
Update: The user with the problem retired the computer and replaced it (which solved the problem)