Develop Reference

Event when dragging over valid drop target outside of app?

I have a very simple method that writes a file locally but I only want to fire it if the user looks like they are going to drop outside of the app because firing it every time they start dragging would result in lots of unnecessary files being written.
So my question is: if a user drags something within the app outside of the app, is it possible to detect when they drag over a valid drop target (e.g. the desktop or windows explorer)?
EDIT: At a more general level, my question is: how can I respond to mouse/drag events that occur outside of my app?

Not entirely sure what it is you're exactly trying to achieve, but this may help:
WPF: Drag and drop virtual files into Windows explorer
For the most part the drag / drop events should fire regardless of where you're dropping to (I think), but you can certainly be notified when a drop has been performed.
As #Quarzy stated, unless you're in communication with the other app, there may be no direct way of testing for data that the underlying windows drag / drop system doesn't expose.
More specifically that question points to this article: http://blogs.msdn.com/b/delay/archive/2009/11/04/creating-something-from-nothing-asynchronously-developer-friendly-virtual-file-implementation-for-net-improved.aspx
I post this purely because I wonder if maybe it may lead to other things, apart from that you might be able to get the Hwnd of the control under the cursor - possibly http://social.msdn.microsoft.com/Forums/windows/en-US/3df9fc84-4020-4ae1-8b4f-942bce65568f/find-the-object-under-the-mouse?forum=winforms as a starting point.
There may then be a way to query whether that particular control is a valid drop target through interop as well.
Good luck!

This might be a possible answer for your question: Register a global hook to detect whether mouse dragging files/text
How ever the following suggestion might help (Require you to create c++ external lib):
Capture other possible processes window message (Global hook WH_GETMESSAGE) (See this link How to Create a global WH_GETMESSAGE HOOK without DLL)
Listen for WM_DROPFILES
see the following link: http://www.experts-exchange.com/Programming/Languages/CPP/Q_10203575.html

You have also an helping answer here How can I capture mouse events that occur outside of a (WPF) window?
But I do not see any way to detect if the target is valid, as long as you have no communication with the potential targets.

Windows Form Appbar Desktop Resizing

Okay. Just when you think you've figured it all out, you haven't.
I have coded and tested a functional appbar class. When I use a simple Windows Form to extend and test the class, it works without issue in both XP (SP 3, 32 bit) and Windows 7 (64 bit). Other windows are accessible, and they all maximize appropriately. However, when I take my "complex" Windows Form (i.e. it is an application) and derive it from the appbar class, the desktop seems to "kick" it out. By this I mean that everything sizes appropriately initially, but then the desktop resizes itself back to its former size. Sometimes this happens rather quickly after putting the form into appbar mode, other times it happens when I click outside the form (to open a browser, for instance), and other times it happens when the form calls a MessageBox. I have put all of the Forms functions in a background worker thinking that may be the issue, but the result is the same. I've posted three images below. The first one shows the application as its initial WinForm. The second shows the appbar "functioning." The last shows the appbar not "functioning." If you're having issues seeing the problem, pay attention to the Recycle Bin. Any ideas?
Edit:
I found these calls via logging. They appear to fire off each time the desktop resizes to "normal." Now I'm trying to see if there is or is not a similar pattern in the "simple" version.
msg=0x6 (WM_ACTIVATE) hwnd=0x1e03ea wparam=0x0 lparam=0x0 result=0x0
msg=0x1c (WM_ACTIVATEAPP) hwnd=0x1e03ea wparam=0x0 lparam=0x1a90 result=0x0
msg=0x1a (WM_WININICHANGE) hwnd=0x1e03ea wparam=0x2f lparam=0x9fe048 result=0x0
msg=0x1a (WM_WININICHANGE) hwnd=0x1e03ea wparam=0x18 lparam=0x9fe038 result=0x0

So this was one wild goose chase. In the event my last comment sounded absurd, it was. While I am still not 100% certain as to this theory (someone please prove/disprove at your leisure), the two different handles came from (1) instantiation of the Form and (2) the actual handle when the Form is loaded. I presume the API follows the same concept of QUERY_POS and SET_POS, that being it initially checks for and assigns a valid handle. Then, prior to the Form being shown, it double checks the handle value.
Long story short, one line of code to verify the handle value in the Load event solved the entire problem.
EDIT:
Better yet, the HandleCreated event is irreplaceable.

WinForms application becomes randomly unresponsive

We are building a WinForms based app (using .NET 3.5)
Recently i have encountered that when performing one of our application's main workflows, the application will become unresponsive in a matter of seconds, failing to properly render the UI (Shows the "Program is not responding" message).
We have reduced the issue to a suspected line of code that adds a tooltip to a label control:
ToolTip tooltip = new ToolTip();
tooltip.SetTooltip(label, "something");
I have spent the past 2 days figuring out what in this code could code any issues with the UI thread, but failed to do so.
My question is -- is it possible to use a performance profiler to gather information about code such as this? Note that the ToolTip class belongs to WinForms and i do not have the source code available for it.
Removing these lines seems to solve the issue completely.
I would like to reduce debugging efforts in the future, as this issue can manifest in other locations of our codebase.
EDIT:
The only similar reported issue i could find was this: WinForm ToolTip.SetToolTip is Hanging my application :(

You could use a program such as JetBrains DotTrace to see what is happening that actually causes the program to halt

I have the same problem, except I use a ToolTip object placed using the designer and then in the Popup event of the ToolTip I set the text for the ToolTip.
The problem only occurs on Windows 7 64-bit (I don't have a possibility to test 32-bit Win7), on 32-bit Windows XP, this works fine.
edit: i guess there was some recurrent calling of the popup event, because when i moved the tolltip setting to other place of my code, it works OK.

I know that this is an old question, but the hanging still happens on Windows 10 64-bit edition. On Windows 10 32-bit everything works fine. I have not looked at the .NET source code, but it must be a wait or something. So to overcome this problem I added the following workaround:
this.Invoke(new Action(() =>
{
tooltip = new ToolTip();
tooltip.SetTooltip(label, "something");
}
));
I was already calling this from the main thread, so according to MSDN documentation this doesn't make sense, but it releases the wait lock or something.

.NET/C# debugging: How to debug a classical heisenbug?

Recently, I've run into a classical Heisenbug. Here's the situation:
I have a tree list, the master view, in one panel, and a detail view in another panel to the right, that displays information about the currently selected tree node. (Very similar to Windows Explorer.)
When I add a new node to tree (think of right-clicking a folder in Windows Explorer and saying "New -> Folder"), the newly created node gets selected.
And here's the bug: The detail view on the right should get updated to show the new node. However, it doesn't. I have to switch to another tree node once, before I can see information about the new node in the detail view.
The bug is easily reproducible and happens in both "Release" and "Debug" build configurations. But: As soon as I set a breakpoint in the event handler (for the "Add new node" menu entry) and enable it, everything works fine =>Heisenbug! I don't have to do any real debugging. Clicking "continue" after the breakpoint gets hit is enough.
For better understanding, I've made a video that should illustrate what's going on.
Everything I could think of to get rid of the issue was putting the thread (the application is single-threaded) to sleep for a few seconds, but that doesn't work.
I'd greatly appreciate any suggestions on what I could try to determine the cause of the issue. Or maybe someone has a guess about the cause?
I'm targeting the 3.5 framework and using x86 as solution platform. The tree list control is from DevExpress' WinForms controls; Visual Studio version is 2010.
Thanks
Update 3: Issue solved. The problem was that the call to the detail view's Focus() method didn't trigger the GotFocus event, which is crucial for updating the detail view. (I don't know why, probably it already had the focus.) However, the method did not fail, it simply did nothing.
Now I just focus another control before focussing the detail view and that's it. The reason why everything worked fine during debugging was that switching from Visual Studio back to my application correctly set the focus on the detail view.
A major obstacle in hunting down this issue was that setting a breakpoint in the GotFocus event handler is useless: anytime you try to switch back from Visual Studio to the app, the GotFocus event gets re-triggered, and you're stuck in an endless loop. Comments on how that could be worked around are welcome.
Anyway, my specific problem is solved.
Thank you very much to everybody who answered or commented. It helped me a lot.
Update 2: In my code, I select the newly created node in the tree. This triggers a FocusedNodeChangedEvent. In the corresponding event handler, I update the detail view and call its Focus() method.
It seems as if that fails when there's no breakpoint set. I think what triggers the correct update during debugging is that the detail view automatically gets the focus.
Window messages
Update 1: Here are the window messages that Eddy's answer provided. (Long list of messages deleted)

First time I've seen a video to support an SO :)
I'm thinking that the right-hand pane, or control group, need(s) to have Invalidate() called - which I think the breakpoint is triggering because it switches to VS, overdrawing the window. Then, when you switch back again, it forces everything to redraw, thus making it work.

When you have a "heisenbug" you need to see what is going on but with a lighter touch that doesn't interrupt the flow of the program.
I would suggest that you form an hypothesis about where your problem lies. I would then edit the code to include calls to the various methods of the Debug class, that test the hypothesis or just give runtime information for diagnosis. Then run your code in debug mode and see what you get in the output.
If you have a more elusive "hiesenbug" theat occurs only in release mode you would need to roll you own logging mechanism to gather your evidence.

Put a System.Diagnostics.Debugger.Break() in the update routine for the other window. Then when the bug appears, a run time break point will be fired and you can view the stack.

It seems that the problem has to do with not getting the right event called to trigger and update to the child panel. When hitting the breakpoint your app loses focus and when you return it gains it again (which is a difference from running it). In order to inspect what events are and aren't called and what the difference is between the two scenario's add the following code to your form to see all the window messages that appear.
protected override void WndProc(ref Message winmsg)
{
base.WndProc(ref winmsg);
System.Diagnostics.Debug.WriteLine(winmsg.Msg + " - " + winmsg);
}
Comparing the differences might help you in determining a way how to workaround this problem.

"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)