Rob's solution works nicely for bitmaps within a label but not so well for moving controls within the main window if you have a status bar :-(
Well, if you think of the example like this:
+ - - bitmap - - - - - - - - - - - - - - - - - - - - - - +
| |
| +---------------------------------------------+ |
| titlebar |
| +-------------------------------------------+-+ |
|+--Label----------------------------------+| |
| || || | |
|| || |
| || || | |
|| || |
| || ||^| |
|| ||v|
| || || | |
|| || |
| || || | |
|| || |
| || || | |
|| || |
| |+-----------------------------------------+| | |
+-------------------------------------------+-+
| |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
Which is to say, you think of the client area forming a window on the bitmap, and the Top and Left methods as setting the part of the bitmap that is visible, then that might give you a clue to how to a achieve your goal.
Ie. If instead if placing your controls as direct children of the main windows client area, you make them children of another window (probably a dialog) and make that window a child of the client area, (in the same way that the label is a child of the client area above), and then you can position the dialog relative to the client area whilst leaving all the controls the dialog contains in fixed positions within it.
The status bar would be fixed to the frame outside of the client area so that it is always visible.
That said, I find the idea of using a scrollbar to find different controls intensely annoying. I have a image app that works that way and often find myself making an adjustment to one control near the top of the list, scrolling down to find and make another small adjustment, scrolling back to re-adjust the first. An intensely frustrating experience. So, unless the scrollbar takes the user through a sequence of operations from top to bottom, not random access, then I'd avoid a scrolling controls interface. If fact, even if the scrollbar does indicate a one-way flow from top to bottom, I'd still much prefer a tabbed interface going left to right with logically grouped controls.
Another alternative is something I implemented (in Win32 a long time ago), where I had too many controls, that required frequent random access, to comfortably fit on a single display. In that case, I reduced each of the controls to an icon or an (industry standard) abbreviation, next to a small edit field showing the current numeric (float) setting. Mousing over the icon or text popped up a small window adjacent contain a slider, buttons or dial as appropriate and took the mouse and keyboard focus to allow it to be adjusted. Moving the pointer (or tabbing) outside that popup cause it to disappear leaving the new value displayed in the edit field. Subtle use of different, muted tones of colored background grouped the controls in logical groups. PgUp and PgDn (or Alt-tab) moved the keyboard user quickly between groups; and Tab quickly within them. Tabbing to a control popped up the adjuster, and the arrow keys made the adjustment (and in combination with Alt, Ctrl and Shift varying the granularity of the adjustments). Or the required value could be typed in directly.
At the time, that design was seen as innovative and was highly praised.
Anyway, some food for thought. I won't be able to help you much with Win32::GUI code; I had a go at getting it installed on my system again yesterday, and it's going to require too many changes to my setup to get it working. I'm due to upgrade my system any day -- though I've been saying that for the best part of a year :) -- so I'm not into making changes that might destabilize it before I get the new hardware.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit |