I’ve got an application at work for which I need to be able to absolutely control the (non-maximzed) window size*.
The application itself isn’t managing its own window size - that is to say that there isn’t an .ini file, and there aren’t any keys in its own branch of the HKEY_LOCAL_MACHINE\SOFTWARE tree that pertain to anything about the application window - so I assume it’s just letting Windows remember it.
But where (presumably it’s in the registry somewhere) is XP storing the remembered window size?
Installing additional software to manage this is not an option, BTW.
*In case anyone is interested. it’s a spatial application that uses a third-party map control which is primarily for use as a visual form object - and it works fine in that way, however, when the object is used to extract a section of the map for the purposes of exporting it (to a document, etc), the shape of the map selection is affected by the aspect ratio of the application window, whereas the exported bitmap is constrained to 4:3 aspect ratio - and this appears hardcoded.
So what I’m looking for at present is a workaround to ensure that the non-maximised application window is exactly 4:3-shaped, until such time as the supplier fixes this bug/limitation.
It probably varies by application, but I think correct practice is to use the user’s section of the registry. As an example, I just tried it with the application FRHED, and it stores last window position in keys such as HKEY_CURRENT_USER\Software\Frhed\Settings\0\iWindowX . (HKEY_CURRENT_USER is a shortcut to HKEY_USERS<your SID>)
That’s where an app *ought *to store its per-user settings. Which window size/location *ought *to be.
Also, if the app is 32-bit and is running on 64-bit windows then you need to explore under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node and HKEY_CURRENT_USER\Software\Wow6432Node. That’s where Windows 64 will stick the settings of any 32-bit app.
Finally, .Net applications tend to store config information in a whatever.exe.config xml file which can be in the program folder or the (I’m too lazy to look it up) folder tree within the user profile folder. If you can determine that the app is in fact .Net -based then we can explore this possibilty further. Config behavior depends a bit on which .Net Framework version the app uses, so determining that will be helpful too.
Assuming the data is stored in any of those places, I can see how you could probably lock down the settings using ACLs so the app always opens with a correctly sized window. But I’m not seeing any way for you to prevent your user from changing the window size then doing the export.
Just a quick note here… Windows doesn’t remember an app’s window size. The app itself decides how large a window is going to be when it asks Windows to open one. If the app doesn’t specify a window length or width value (by giving Windows the CW_USEDEFAULT flag rather than a specific size parameter) then Windows selects a generic value based on its screen size and where the upper-left-hand corner of the window will be located.
If your app is starting up (or can be coerced into starting up) with a window size that’s different from the generic default then your app is remembering that window size somewhere. These days, that’s probably in the registry somewhere.
Thanks for the information folks. Turns out it’s not actually remembering the size (I was mistaken). It’s setting its own non-maximized size at something that causes it to output distorted bitmaps - when maximized, it works, but not if used on a widescreen monitor.
Looks like I’ll have to press the supplier for a fix a bit harder than I first thought…
Can you run it in compatibility mode for 640 x 480? It’ll change your screen resolution every time you start and exit it, but it’s at least a temporary workaround…
It’s a good idea, but I don’t think that will help - the title/tool/menu bar in the application stays the same height whatever size the window is set to. On a 1024x768 screen, this makes the map workspace exactly the right shape to fit the shape of the exported bitmap (they’ve hardcoded it this way) Terrible design, but maybe the choices were limited by the component they used.
To run it at any other size, I’d need to adjust the height to take the non-scaling furniture of the application window.
You could write an AutoIt script to set it to your desired size. Either use the script to launch the application, or leave the script running and have it watch for the application.