There is an application written in Java using AWT. And I want to resize its windows by an external program. My OS is Windows XP. Actually this application is an online poker client.
The windows are of "SunAwtFrame" class, so I look for those windows and call MoveWindow/SetWindowPos on them. The result is not the one I expect:
a problem http://savepic.net/1331700.png
As you see, the window did resize, but the content did not. While resizing manually it scales, and I want the same behavior here.
Probably, some additional action are needed to make AWT windows understand it was resized.
How can I fix the problem?
I recommend doing this:
Use Spy++ (available as a tool in Microsoft
Visual Studio) to filter messages sent to the SunAwtFrame window.
Resize window manually.
Figure out which messages are sent to the window during resizing. Use
MoveWindow/SetWindowPos and/or send those messages after you resize.
Take a look at functions InvalidateRect and UpdateWindow.
Related
My application is a fullscreen window which is rendering a designated other window (from dwm), for example Google Chrome. I would like to know if it's possible to send events (such as mouse keyboard events) to the specified window.
Of course the designated window has to stay in background, and my current application on the foreground.
My application is written in C++. I'm working on Windows 7/8.
Just to put it into an answer.
Based on this question Does any program/language/library that interacts with windows do it via the WIN32 API? you should be able to use the windows API to send a windows message to any window. All you need to get is that windows handle, or you could do a broadcast to all windows.
The specific function http://msdn.microsoft.com/en-us/library/windows/desktop/ms644950(v=vs.85).aspx
Though that function will block until the windows responds and processes the message, this could hurt GUI performance. If you notice issues try implementing http://msdn.microsoft.com/en-us/library/windows/desktop/ms644951(v=vs.85).aspx instead.
I am experimenting with a home-grown application hosting framework, and I'd like to abstract the input/output so I can gracefully handle crashes. Chrome uses a very similar model.
Is there any way I can take an arbitrary window handle, and persuaded it to start rendering to a back-buffer? Or should I create my own window first, and then reparent the client app into it?
As the comments said you can do anything if you're willing to dig in and hook the APIs themselves, but according to the remarks in the MSDN WM_PAINT page WM_PRINT is the supported way to force a window to paint on a specific DC.
It sounds like you also need to keep the window from showing up on the desktop - in that case you can use WM_SETREDRAW as described in On Win32, can I disable painting of a window for a period of time?.
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 want to get the window handle of some controls to do some stuff with it (requiring a handle). The controls are in a different application.
Strangely enough; I found out that many controls don't have a windows handle, like the buttons in the toolbar (?) in Windows Explorer. Just try to get a handle to the Folder/Search/(etc) buttons. It just gives me 0.
So.. first question: how come that some controls have no windows handle? Aren't all controls windows, in their hearts? (Just talking about standard controls, like I would expect them in Windows Explorer, nothing customdrawn on a pane or the like.)
Which brings me to my second question: how to work with them (like using EnableWindow) if you cannot get their handle?
Many thanks for any inputs!
EDIT (ADDITIONAL INFORMATION):
Windows Explorer is just an example. I have the problem frequently - and in a different application (the one I am really interested in, a proprietary one). I have "physical" controls (since I can get an AutomationElement of those controls), but they have no windows handle. Also, I am trying to send a message (SendMessage) to get the button state, trying to find out whether it is pushed or not (it is a standard button that seems to exhibit that behaviour only through that message - at least as far as I have seen. Also, the pushed state can last a lot longer on that button than you would expect on a standard button, though the Windows Explorer buttons show a similar behaviour, acting like button-style checkboxes, though they are (push)buttons). SendMessage requires a window handle.
Does a ToolBar in some way change the behaviour of its child elements? Taking away their window handle or something similar? (Using parent handle/control id for identification??) But then how to use functions on those controls that require a windows handle?
If they don't have a handle, they're not real controls, they're just drawn to look like controls.
But of course, the toolbar buttons in Windows Explorer do have window handles, they're part of a toolbar. Use the toolbar manipulation functions to interact with them, not EnableWindow.
Or, better yet, use the documented APIs for things like search. Reverse-engineering Windows Explorer has never ended well for anyone, least of all the poor Windows Shell team, saddled with years of backwards-compatibility hacks for certain developers who thought that APIs are for everyone else. Whatever you do manage to get to work is very likely to break on the next version of Windows.
The controls you are talking about are using the ToolbarWindow32 class. If you want to interact with them then you'll need to use the toolbar control APIs/message. For example for enabling buttons you'd want to use TB_ENABLEBUTTON.
You can implement the controls yourself using GDI, OpenGL or DirectX. Try Window Detective on Mozilla Firefox and you will see that there is only one window. Controls in dialog boxes are not windows known to Windows.
I am trying to write a program that gets the windows that are displayed on the screen. Something like screen.getActiveWindow().size would be cool, but it only addresses the active window.
I am looking for the sizes of all windows on the screen, as well as event information when they are resized, cover each other up.
Am I just daydreaming or is there a way to get this information on windows?
You need to use EnumWindow Function go get the hwnd of each window then user EnumChildWindow to get the child windows and finally get windowinfo the clr doesn't have all of the necessary function to do low level window manipulation unless its been added in 4.0 and I haven't noticed.