Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re^2: Win32 GUI scrolling controls within the main window

by SteveR (Novice)
on Jun 07, 2017 at 19:08 UTC ( [id://1192299]=note: print w/replies, xml ) Need Help??


in reply to Re: Win32 GUI scrolling controls within the main window
in thread Win32 GUI scrolling controls within the main window

I have read that link thanks, its really good and about the only bit of code or explanation that I could find over the last few days

However I do have a few questions about it as the vast majority is to do with moving the scrollbars around and displaying them. The scroll bars don't actually scroll the image until part 7. The bit that must be doing the work is

sub process_scroll { ... if ( $bar == SB_VERT ) { $self->BM->Top( -$new_pos ); } else { # SB_HORZ $self->BM->Left( -$new_pos ); }
I looked up Top on the Win32::GUI::Reference::Options and its says

-top => NUMBER Specifies the top position (Y coordinate) for the window, in pixels. For Windows and DialogBoxes is absolute (screen position), while for controls is relative to the client area of their parent window.

So what I don't understand is how moving the top or left hand side of the Label control (that has the bitmap attached and is not actually anchored to a specific part of the main window or is it) causes the image to scroll ?????

If it isn't that bit of code then what is doing the work ?

Replies are listed 'Best First'.
Re^3: Win32 GUI scrolling controls within the main window
by BrowserUk (Patriarch) on Jun 07, 2017 at 20:05 UTC
    -top => NUMBER Specifies the top position (Y coordinate) for the window, in pixels. For Windows and DialogBoxes is absolute (screen position), while for controls is relative to the client area of their parent window. So what I don't understand is how moving the top or left hand side of the Label control (that has the bitmap attached and is not actually anchored to a specific part of the main window or is it) causes the image to scroll ?????

    As far as can tell, in this line:$self->BM->Top( -$new_pos ); is telling the label (a client window, thus relative positioning) containing the bitmap, which part of the bitmap to display.

    If you move the vertical scrollbar down 3 units, it needs to reposition the top of the bitmap -3 units above the top of the label client area, thus hiding those top 3 units worth of bitmap.

    Does that make things any clearer?


    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.
    "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
    In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit

      That helps thanks

      So that would imply that moving the contents around is 100% the scripters problem

      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 :-(

      I will do some experiments to find a way to contain the labels to stop them from going over the top of the status bar and to get a pair of scroll buttons

        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.
        "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
        In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
        but not so well for moving controls within the main window if you have a status bar :-(

        Hey, why not switch to Perl/Tk which works great across platforms. It would make the job trivial. :-)


        I'm not really a human, but I play one on earth. ..... an animated JAPH

      I have managed to create a solution which lets Win32::GUI::Grid do the work for me

      That gets me an area of the screen that holds my Labels (in practice these are a 4 wide x X deep grid of pictures for my app) The labels are contained by the grid and no longer go over the status bar and the Grid control makes the scroll bars around itself appear and disappear as needed.

      In its simplest form here is some code.

      I would recommend using $Grid->AutoSize() just before $main->Show(); for a real grid to do the sizing but for this eaxmple I wanted 80 x 80 cells to make the scrollbar appear

      If you resize the window then the scrollbr should come and go

      use Win32::GUI; use Win32::GUI::Grid; use warnings; use strict; my $main = Win32::GUI::Window->new( -name => "Main", -title => "Test", -pos => [100, 100], -size => [200, 200], ) or die "new Window"; my $Grid = $main->AddGrid ( -name => "Grid", -pos => [20, 20], ) or die "new Grid"; $Grid->SetColumns(1); $Grid->SetRows(2); $Grid->SetRowHeight(0, 80); $Grid->SetRowHeight(1, 80); $Grid->SetColumnWidth(0, 80); $Grid->SetCellText(0, 0, 'Cell 1'); $Grid->SetCellText(1, 0, 'Cell 2'); my $sb = $main->AddStatusBar(); $main->Show(); Win32::GUI::Dialog(); sub Window_Terminate { return -1; } sub Main_Resize { $sb->Move(0, $main->ScaleHeight - $sb->Height); $sb->Resize($main->ScaleWidth, $sb->Height); my ($width, $height) = ($main->GetClientRect)[2..3]; $Grid->Resize (110, $height - $sb->Height - 20); }

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1192299]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (4)
As of 2024-04-19 04:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found