Although giving the form a vertical scroll bar is easy to do, it might not be the best option from the user's point of view. Users sometimes fail to notice the scroll bar and don't realise that they need to scroll down to see the rest of the information.
A better way of showing a lot of information on a single form might be to use a page frame. This has the advantage that you can arrange the information in logical groups, with a separate group on each page. But this is largely a matter of personal taste, so decide for yourself whether to go down that route or to stick with a vertical scrollbar.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
The only thing I ever used scrollbars was for an image viewer with zoom. Otherwise there are a lot of scrollable control, too, the grid mainly and listboxes. Mike already mentioned the pageframe.
I agree with Mike that it's not very usual to have scrollable forms, you also have to put things on the oversized form canvas at design time to be able to scroll at all, that makes it less good to handle designing oversized forms. The design of a container having a section of what you want to display and using that in a grid is easier, as grids have scrollbars, naturally. Such a grid only needs 1 column and that columns control has to be the container instead of the text1 textbox and then you can repeat whatever container or even use danamiccurrentcontrol to have different containers per record.
Another reason for a form not to have a vertical scroll bar is that there will usually be certain controls that you want always to be visible. For example, the form might have a large number of labels, text boxes, combo boxes, etc. - too many to fit in the visible portion of the form. So you allow them to scroll. But the form would probably also have some buttons, such as Save, Cancel, Close, etc. that you want always to be visible. You can't do that with a scrollable form.
However, it is possible to create a scrolling region within a form - where some of the controls can scroll and others remain stationary. I described how to do that in my article "Create a scrolling region within a form" (with help from Bernard Bout and Fernando Bozzo). It's not an ideal solution, and it doesn't work in all circumstances, but it might be worth a glance.
That said, I still prefer to use a pageframe to deal with this issue.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
I wanted to suggest you could have an oversized form within a _screen that has scrollbars without adding scrollbars to the form itself as an alternative solution. But then I tried, failed and noticed the help says the scrollbars property is ignored for _Screen. That just illustrates once more how rarely I have use for this.
But now I'm a bit curious for what you'll use the scrolling of the form itself.
Another benefit of the pageframe is that you do not have to initialize all the controls on the pages not initially visible. You can use the Click() event for each of the pages to initialize the controls such as populating grids. This allows the form to open faster and only populates the data for the page if the page is actually accessed.
I actually turn off the tabs property (Tabs=.F.) to hide the pageframe tabs. I have a commandgroup control that has a button for each page. In the InteractiveChange() event I set the appropriate tab via:
Wow! Thank you so much Mike, Chriss, Steve and Ggreen... Ive realised that i need a lot more to study and learn... Thank you for your substantial answers and suggestions... God bless...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.