Yes, AutoHotkey limits the automatic size to the width and height determined via
SystemParametersInfo(SPI_GETWORKAREA, 0, &work_rect, 0);
// Seems best to restrict window size to the size of the desktop whenever explicit sizes
// weren't given, since most users would probably want that. But only on first use of
// "Gui Show" (even "Gui, Show, Hide"):
Code: Select all
Gui, Margin, 15, 15
Gui, Add, Edit, w3000
Gui, Show, Hide ; First use
Gui, Show, AutoSize ; Second use
Windows also prevents windows from becoming (much?) larger than the virtual screen, but not with complete consistency. For instance, if I make the window resizable, attempting to resize it limits it to 1942 pixels wide with my 1920x1080 screen.
In my case the problem is that my GUI has to be physically big because it relies on small clickable areas on an image. If it's too small, it becomes too difficult to aim for these areas. I plan to run my script on a bigger screen but I'm currently on the road and only have my small laptop to work with.
I don't think that explains why you need the GUI to be larger than your screen. You can't see what's not on the screen. I'd guess that you move the window around in order to view different parts of the image, but I think allowing the image to scroll or move within the GUI would make more sense and be easier to use (it just wouldn't be as easy to implement).
One way would be to allow dragging the picture with the mouse. You can detect left-click by monitoring WM_LBUTTONDOWN with OnMessage, or use a hotkey, and then monitor the mouse position with a timer or loop and move the control within the GUI correspondingly.