I asked this over at StackOverflow and someone suggested I try here, so...This program uses winforms and c# (no wpf). I have a panel with buttons on it and getting it to scroll is no problem. However, when the program is on a hi-resolution touch screen -- like a Surface 7 -- trying to touch in the exact right spot to get it to scroll is hit and miss. I've searched and have yet to find a way to make the grab area (so to speak) of a vertical scroll bar wider so that when you touch the screen, the control actually picks up the event. Any ideas on how to do this?
This can be a super user question if youre looking for a tool to make it wider for all apps because it could be considered as an accessibility.
If you're writing an app
Vertical Scroll Bar Width
System.Windows.Forms.SystemInformation.VerticalScrollBarWidth;
Horizontal Scroll Bar Width
System.Windows.Forms.SystemInformation.HorizontalScrollBarHeight;
Duplicate of
Change width of scrollbars
Related
I'm trying to make Xamarin forms application, in which the data should look like this.
However, it can be seen that the height and width of the view are large and I need to scroll the page both horizontally and vertically. So, when I scroll only the data portion should move while the A and B axes stay constant. If I move to column B6 then the view should be as shown below
and from this point if I move row A5 the view should be as shown below.
I'm quite new to xamarin forms or any other android development programming. At this point, I'm just trying to know what kind of search terms that I should use where I can find some documentation related to make such kind of view in my application. I guess a simple idea can be just using a scrollbar but I need my axes points visible all the time even if I scroll far right or far below.
Any suggestions?
Thank you!
To your question, you can search with scrollview, it is a layout that's capable of scrolling its content. You can set the orientation of your scrollview as "both" so it can scroll both horizontally and vertically.
But it can only have one content to scroll. It means scrollView objects should not be nested with other controls that provide scrolling, such as CollectionView, ListView, and WebView. For more information, you can refer to https://learn.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/layouts/scrollview
I am having difficulty getting both the vertical and horizontal scroll bars to behave as desired in my situation. The page in question has multiple sections that can be expanded and collapsed (only one can be expanded at a time). To try and demonstrate the layout of my page I'm going to use nesting and perhaps a silly naming convention to be as clear as possible:
ucParent
pnlParent
pnl1Title
pnl1
uc1
pnl2Title
pnl2
uc2
pnl3Title
pnl3
uc3-1
uc3-2
uc3-3
And so on. Now, pnlParent has dock=fill, while the child panels are dock=top. All the pnlXTitle panels have buttons that trigger the expanding/collapsing behavior by setting their respective panels directly underneath to enabled=visible=false.
I'm wanting the horizontal and vertical scroll bars to show up as needed when the window is resized and hiding content, however I am not being successful at eliciting this behavior.
With ucParent.AutoScroll=false and pnlParent.AutoScroll=true only the vertical scroll bar is present.
With ucParent.AutoScroll=true and pnlParent.AutoScroll=false neither scrollbar works.
With both ucParent.AutoScroll=true and pnlParent.AutoScroll=true only the vertical scroll bar is present.
In all the above examples, AutoScroll=false for all the other panels and user controls. From what I've read so far, I fear the dock=top setting may be interfering with the horizontal scroll bar behavior. I can force it to display and work by using AutoScrollMinSize, but the panels are of different sizes making this feel like much more of a hack than a proper solution.
Through my searching I found a good number of previous discussions revolving around Windows Forms and scrollbars, but I didn't find anything specific enough I feel I can confidently determine the necessary direction for my application. I would very much appreciate any information you could share that would shed light on why the scroll bars are not working as desired and how that can be remedied.
Thank you!
The problem you're experiencing has to do with the way that docking resizes your controls to fit horizontally within the form.
When you dock a control to the top of its container, it is stretched to fit within the container. Consequently, no part of it falls outside of the container, and there is no need to display the horizontal scroll bar. This is why your scroll bar isn't appearing.
This behavior is by design.
I'm faced with a problem: I am trying to automate a control with UI Automation. The control is a viewer in a client application, which hooks into a service hosted remotely. As a result of some legacy design decisions, this viewer simply displays a bitmap on a canvas. When interactions occur (e.g. clicks), the position of the click is sent to the service, which uses the co-ordinates to work out where the click occurred, and react correspondingly. The result of this is a nightmare for UI test automation. There is no way of hooking directly into sub-controls, because they are simply painted on to the bitmap. I have found a back-end way of accessing information about what is in this canvas, but now I need to work out where, in this scrolling bitmap, those items appear, so I can interact with them. I use positional information based on the upper part of the control, but since I don't have access to the bounding rects of these sub-controls, as soon as I scroll, all this information becomes invalid. My main problem is that I can't work out how far the scroll bar moves the canvas. Since scroll bars in UIA only have values from 0-100 (despite the actual magnitude of the scrolling effect), I can't work out how far down the canvas I've moved from a known position (it would depend on how far the scroll bar can move at that given time - i.e. how many sub-controls have been rendered in the bitmap). Is there any way of working out the magnitude of the scroll event on this canvas? I know that this must be done internally - the scroll bar has to know how far to move the canvas, based on the actual size of the canvas. However, the bounding rect of the canvas only gives it's visible on-screen position - it doesn't indicate how big the underlying image is. I either need to get the full size of the bitmap (as if it was rendered fully on screen, without scrolling), or to know how much adjusting the scroll value effects the visible position of the image. Is there any way of working this out?
A disclaimer first! This might be a very fundamental question, but I have started learning Winforms Application Development on my own (.net 3.5,C#), and I have this resizing question.
I am developing a small Winforms application that has a standard tab control (along with many other controls) placed in the form. (It has 5 TabPages)
The AutoScroll property for the TabPage has been set to “True”. On reading up what I got to understand is that this will enable the scrollbars to show up at run time while resizing. i.e if the height of the form is reduced it will cause the vertical scrollbar to show up within the TabPage.
While the application is running, what I noticed is that if I reduce the height of the form using the little double headed arrow, the scroll bar does not stay on top, i.e if I adjust the height from below, the bottom end of the scrollbar is no longer there. More precisely I am just looking for a way to keep both ends of the scrollbar on top within a TabPage when the form containing the Tab control is resized.
It sounds like the problem is that the tabbed control will show scrollbars and may well autosize, but you haven't told the form what to do.
You might want to look at the 'Dock' property of controls, which causes a control to fill a specific area of the form (or other parent control), no matter what it is resized to.
Ok, I have googled, but maybe I put my search in weirdly. :/
I have a VB.NET WinForms application. I have the anchor properties set for all the controls so that it will resize all the controls to look decent when the form is maximized. (Haven't gotten around to manual resizing yet however).
Anyway, the problem:
I go to set the same properties for a button (testing with a single button for now) on the main GUI form/picture. When I go to run the program via F5, it looks decent. But when I maximize the form, the entire button covers up more than it should.
I've taken screenshots of the form so you can see a visual of what I'm talking about. :/
Before: http://zack.scudstorm.com/before.png
After: http://zack.scudstorm.com/after.png
What other propert(y|ies) do I need to set for the buttons to show up correctly? :/ (The buttons go over the boxes that say, for example, "1-1", "2-3", etc.
Thanks,
-Zack
Seems like you have anchored top-left and bottom-right when what you want is just top-left.
Edit: If it's just an image that does not change when the winform changes, then don't anchor your buttons at all. Just put them where they go. If you are scaling the image, then I would either detect the clicks on the image and do the scaling math or do the scaling math and set my buttons in code in the Form.OnResize event.
As it appears that your goal is just to be able to handle clicks on the "computers"...
One option that can be useful for this sort of task is to create an "overlay" bitmap (not displayed, but which is the exact same size as your source bitmap) which uses different colors to represent all the clickable regions. (e.g. (R=0,G=0,B=0) for computer 0, (0,0,1) for computer 1, etc)
You could even generate this bitmap somewhat automatically without too much trouble (If you have a mode where you can click the top left and then bottom right corners of the image to define a new region)
When the mouse is clicked, you can check the pixel at the scaled coordinates of the mouse position in the overlay and determine what their click corresponds to. This can be a lot easier than creating loads of controls, and makes it a lot easier to have clickable regions that aren't rectangular.