This is a kind of a complex query as it look it from outside. I would like to get notification about any drag/drop operation performed in windows explorer with exact number of files being dragged from source to target folder.
I have tried setwindowshookex in my application but the drag/drop events doesn't appears in callback function although I am getting resize, forgroundwindows, selection on items etc. events.
NOT sure what is wrong, it might seems impossible to Hook drag/drop events in windows.
Have anyone can help with this.
Thanks
Al
Drag&Drop operations inside of Windows Explorer do not use window messages, they use the IDropSource and IDropTarget COM interfaces via the DoDragDrop() function. You can't hook that with SetWindowsHookEx(). You would likely need to write some code into a DLL and inject it directly into Windows Explorer so it can then hook DoDragDrop() directly, such as with a detour, so any call to it will go through your hook code first. That way you can gain access to the COM interfaces that are passed to it, as well as detect whether the drag&drop was successful or canceled.
Related
I am not sure how to ask the question so here is a picture of some idea that came to mind
So for example, when you run my "custom launcher" it displays a window with a couple buttons on the side which you can assign values to. When you click on a button, the appropriate program will run in the big panel on the right (in window mode).
This is all from the user's perspective of course. They will just see that the program they want to run appears in that panel. The actual implementation may have nothing to do with "one program running inside another program"
My own use case is limited to windows desktop platforms only, but if it is possible to generalize it that would be nice as well.
Is this actually possible? Can I write such a program that will run another program inside a panel? The program that's launched may be someone else's, such as MS paint or calculator.
Just to expand on my comment above, here is an approach that may work for you: Fake it :)
When you launch the program, intercept all windows messages to the program that control it's position on screen. That way it 'appears' to be fixed in place, but in reality it's still attached to the normal Windows desktop.
Here's some light reading for you:
Windows Event Hooks
A hook is a mechanism by which an application can intercept events,
such as messages, mouse actions, and keystrokes. A function that
intercepts a particular type of event is known as a hook procedure. A
hook procedure can act on each event it receives, and then modify or
discard the event.
I would recommend against it in a commercial application because you are modifying the behavior of software you don't own - that software may make assumptions about what its parent window is, but for experimentation there's the SetParent Win32 function.
On Windows, the drag and drop action can be done via COM DoDragAndDrop API, see http://msdn.microsoft.com/zh-cn/library/windows/desktop/ms678486%28v=vs.85%29.aspx. It can perform D&D operation perfectly and has the best system integration.
Recently, I found it is not touch friendly API, it can not handle touch event very well. On Window 7/8, A Win32 window created by CreateWindow API is also able to handle touch event in the same way as handling mouse event. Actullay, it seems the touch events are converted into a similar mouse events, e.g. a mouse down event is triggered when a finger is tapped down, a mouse move event is triggered when a finger is moved.
However, the DoDragAndDrop COM API doesn't convert touch event into mouse event, even the COM service doesn't have any idea about touch event at all. But I had a try to drag a file from one folder to another folder on Win8, it works. If the D&D operation is also implemented based on COM API, I indeed got a conflicting result.
Did I miss something when I use DoDragAndDrop for touch event support? Thanks.
DoDragDrop() does support touch on Win7/8 (and yes, D&D of files is implemented by Windows Explorer using DoDragDrop()), so your problem is related to something else. Did you check whether DoDragDrop() is returning any error code to your code that you may be ignoring?
I have a vb6 application that is using leadtools 14. The codes references the member ShowDirectoryDlg from the Class LeadRasterDlgFile. The end users have requested this diaglog box be made larger. Is this possible?
I don't know this library, and there was no easy way to search for LeadRasterDlgFile on the website. And anyway, I assume that you have scoured the documentation for a way to do this.
This only leaves Windows API calls. You have to use a timer set to fire 1ms after setting the timer to Enabled. Then you call your function. In the timer event loop, use FindWindow() or FindWindowsEx() to get your dialogue window. Next, use MoveWindow() to resize the window. You might also want to resize the child windows. Use GetWindow() to identify child windows. Use Spy++ to check the child window IDs.
Note that this will only work in the compiled application - not in the IDE.
The problem with this is that it is possible that the dialogue does not use standard Windows windows. You will find this out with Spy++.
I am debugging an application which, in its message loop, calls IsDialogMessage(). Occasionally, IsDialogMessage() never returns (where never is an interval greater than 1 hour). Based on the symbols for user32.dll available from Microsoft's symbol server, it appears to be stuck in GetNextDlgGroupItem() (or an internal variant of the same), iterating over some set of windows.
The application is multithreaded and frequently receives notification of external events, which arrive as DCOM calls. I suspect that such a call is handled incorrectly in a way that corrupts some window state. If I can learn what sort of state corruption might cause an infinite loop in IsDialogMessage(), I think I will be more easily able to identify the source of the corruption.
I know this is old, but answering for posterity since no one here mentioned it.
More than likely what is going on is trouble with the windows manager determining where to forward a message. If you have a hierarchy of windows, as you probably do, then you need to ensure that non-top-level windows that contain controls themselves must have the WS_EX_CONTROLPARENT style set. If it is a dialog, you use the DS_CONTROL style. The presence of these flags modify the behavior of IsDialogMessage; they identify a window as having its own controls which can receive focus and handle tab order, etc, rather than just being a control itself.
For example, if you have a main frame window, which has a child window with WS_EX_CONTROLPARENT, which has a child window without WS_EX_CONTROLPARENT, which has a child window that has focus, and you hit TAB, you will likely encounter an infinite loop at the same place you mention.
Setting the second child's extended style to include WS_EX_CONTROLPARENT will resolve the issue.
Are you maybe disabling controls (using ::EnableWindow()) without checking first whether that control has the focus? If yes, then the focus gets lost and GetNextDlgGroupItem() gets confused.
Another reason this can happen is if you reparent a modeless dialog. At least this can happen with wxWidgets...
I've made some investigation, trying to answer this question. But only in situation, when parent window is in native MFC project and child is a managed C# Windows Forms. If you have such situation, then you may try 3 resolutions:
Run MFC dialog message loop on Windows Forms side. Here is more info: Integrate Windows Forms Into Your MFC Applications Through C++ Interop
Create 2 threads: one for Windows Forms dialog and one for native dialog. Here you can create dialog in Windows Forms, then with SetParent() set it's parent to native dialog. But be ware: if you add TabControl to Windows Forms, than hang with "IsDialogMessage() never return" will occur.
Make a wrapper for Windows Forms dialog to use in native project. For ex., wrapper may be WPF, see here: Windows Form as child window of an unmanaged app
I've taken information mostly from: http://msdn.microsoft.com/en-us/library/ms229600.aspx
And the temporary cure can be to change focus behavior. For example, disable them, or SetFocus() to parent or child windows only. But I strongly recommend to investigate the real reason, why IsDialogMessage() never return in your case.
Using WinXP. What I need to do (pref in VB or c#) is to detect when another (closed source) program displays a notification balloon in the tray - and grab the details. Any help would be appreciated. Thanks
In similar situations, I have used the Microsoft tool Spy++ to grab the window information and then uses pinvoke calls to FindWindow to detect when the window is present.
I've not tried with a notification balloon, but I imagine that a pinvoke call to GetText would retrieve the contents.
I think you'll need to use pinvoke to do this from a .net language.
On the system I'm using now (Vista Business SP2), balloon windows always seem to have window class #32769 (reserved for desktop windows) and the windows style bit TTS_BALLOON set.
The following might work: Determine the parent window for all notification balloons by creating a temporary one, getting its hWnd, and calling GetParent() before deleting it. You could then periodically poll the children of this parent hwnd (using EnumWindows() or FindWindowEx()) looking for windows with the required class and style.
This seems highly non-portable to me, and likely to require a lot of testing on a variety of platforms.
pinvoke.net and spy++ might be useful.
Good luck!
You will definitely need to use Win API calls to achieve this. If this is the only thing you're trying to do, you'd be better off using straight C or C++ so you don't have to do a bunch of platform invoke for C# or VB.
Since andyjohnson identified that the window class for all notification balloons is #32769, and that they have the TTS_BALLOON style set, you could use a CBT hook (if you're not familiar with Win32 hooks, you might want to read up on them), to get a callback whenever a window is created, and check for windows of that class and with that style.
I'm not sure, though, if a new balloon window is created for second and subsequent popups or if the same one is just hidden and reshown. If this is the case, you might need a CallWndProc hook, to get WM_SHOWWINDOW messages.
Edit:
I should mention that the hooks that I've mentioned cannot be implemented in .NET. Except for the low-level keyboard and mouse hooks, global system hooks must be implemented in a native (unmanaged) DLL. Windows will load this DLL into other processes, and if a managed DLL gets loaded into a process that doesn't have the .NET CLR loaded, it will crash that process. (Even if the CLR is loaded, it might be at a different address, also causing a crash.)
So you must build your hooks in a native (unmanaged) DLL. It's possible to interface from here to a managed application, such as Michael Kennedy has done on Code Project, but to do it properly, and handle the hook types I've mentioned above, you'd need to use interprocess communication, a step that Michael Kennedy left out. All in all, for the purpose you've described, it would probably be easier to just build the whole thing in native code.