Assume that treeview's Scrollable Property has been set to true correctly.
As the scrollbar appears only when the treenodes is out of the visible area. However, I want it to always showing a blank area below the buttom treenode(where treeViewHitTestInfo.Location == none), while the scrollbar will only expand pettily to show all the treenode. Sometimes, the lowest treenode(whose index is largest at root) only show about 40% of the label in the treeview, and EnsureVisible() don't work at all.
I tried SetScrollRange() in user32.dll to change the scrollbar's height. However, it doesn't work well. It seems that the treeview's "client area" is settled by the system's caculation using my nodes's height and unchangable for me.
Is there a way to force it to expand?
Related
I am trying to place a panel that I want to have multiple textboxes inside of. I want this panel to fit inside the form and the panel to have a scrollbar. I have autoscroll on and its working as intended, but I want to be able to add controls below the size of the panel. Is there a way I can "full screen" the panel and place items in it or even make the scrollbar a set length instead of just the amount needed to fit the contents. I want to be able to place things underneath what I have there.
Dragging items onto the panel doesn't allow enough room to make things tidy
As an option, you can set the AutoScrollMinSize, in your case, the height of it to a larger value like 1000 temporarily, which sets the virtual (Scrillable) height of the control to 1000. The property determines the minimum size of scrollable area.
As another option, you can AutoScrollMargin, in your case, the height of it, to something like 500 temporarily, which provides an extra 500 pixels space at bottom of the panel. The property determines the minimum margin that should be between the edge of the child control and the edge of the scrollable control.
Then when you are done with the design, just right click on the property and Reset the value of it, to let the control calculate the scroll size.
And I assume you are aware of some obvious workarounds like:
Design the form (including the panel) in a larger size, setting proper dock and and anchor properties for controls, later set the size of form to desired size at run-time, or at design time (after you are done with the initial designs).
Or another workaround, could be just dropping the controls in the panel, and then selecting them and moving them using arrow keys.
Here is the problem. If you dynamically place controls in a panel, it works fine, but only until the vertical scrollbar appears. Once there is enough content for this to happen, it starts positioning controls nonsensically.
In my window, you can click a button to add another row of controls inside the panel, which represent options for an item in a list. If you scroll the vertical scrollbar on the panel all the way down and click the button again, the new row of controls will be positioned below the bottom edge of the panel out of view. If you scroll down, there is a huge gap between the new row and the previous row of controls. This should not happen. The positioning code is working flawlessly, as proven by debug output. As far as I can tell, the problem is the stupid anchoring system, however disabling anchoring on these controls does not fix the problem as one might expect. Instead, it just makes it position them wrong in a different manner. This makes no sense at all, and is super annoying!
I tried disabling Autoscroll in code before controls are added to the panel. No change. So I modified that code to disable both the vertical scroll bar and Autoscroll and set the scrollbar to not visible before controls are added. No change again, except that the now disabled vertical scrollbar still manages to appear usable when there is enough content in the panel in spite of it being disabled and set not visible!? That's not supposed to happen when I disabled and made it invisible! With anchoring disabled on the controls being added to the panel and once the vertical scrollbar has appeared, clicking the button to add a few more rows of controls now causes them to be indented a bit for no reason and positioned overlapping each other a bit vertically! It's as if the coordinate system in the panel has somehow arbitrarily changed, because of the presence of a vertical scrollbar and anchoring being disabled on the controls? The debug code shows that the controls are all being placed at correct coordinates, yet they appear positioned very wrongly. So my code is working perfectly, and therefore something else is the problem here.
Everything behaves exactly as expected up until the vertical scrollbar appears. This is so bizarre. Does anyone have any idea what on earth is going on with this stuff? Apparently it is far easier to make it do stupid stuff than to get it working properly.
Thanks again! I got it working. I went with TaW's solution first since it seemed like the simplest solution. Incidentally, I already tried TaW's approach days ago when I was fighting with it, but I had naturally subtracted the AutoScrollPosition value rather than add it, because I didn't expect it to be a negative value!
It seems very odd that control positioning is relative to the current AutoScrollPosition, as absolute coordinates seems like a much more natural, intuitive approach than having negative numbers. I guess that would make it slightly harder to place a control in the currently visible area, but I suppose that's not a big deal as most scrollable interfaces are probably initialized ahead of time and don't need to do that anyway.
I wonder why the child control cannot be scrolled even though it cannot fit its container.
Here is my simple example of the layout:
I have orange panel and green panel inside. Orange panel has AutoScroll set to true.
Green panel is docked to top and has minimum width = 150.
Why the horizontal scrollbar doesn't appear on orange panel?
Without DockStyle=Top everything works fine. I could use Anchors, but I feel more comfortable with docking when creating more complex layouts with many groupboxes and panels stacked on each other.
I also don't like using AutoScrollMinSize because it sets the limit regardless of what controls are currently visible on the form.
The question is why does it work this way?
P.S. Just let me know if this is by design and there is no other way except Anchors on green panel or AutoScrollMinSize on orange panel. It seems weird to me that it cannot display the scrollbar in that case even though you have child control that cannot fit into its parent and parent has AutoScroll=true. I guess the layout engine doesn't even bother calculating the actual width of the docked control because in theory it is stretched to whatever parent width you have.
It looks like this is by design. I checked the code of the ScrollableControl from which Panel and therefore other containers like TableLayoutPanel and FlowLayoutPanel are inherited.
The horizontal scrollbar will not be checked if the child control has:
Dock=Top|Bottom|Fill|Right or Anchor=Right or Anchor!=Left
And the same picture is for vertical scrollbar, it is ignored when the child control has:
Dock=Left|Bottom|Fill|Right or Anchor=Bottom or Anchor!=Top
There is nothing much I can do except using AutoScrollMinSize or right combination of anchors.
I am making a WP7 app which has a Listbox of UserControls. Each UserControl has an ItemsControl and Button(for getting more results). On click of the button the ItemsControl items will be increased by 5 or 10.
Now on clicking on the GetMore button of any of the usercontrols except the first or last, there will be an increase in Scrollable height(Total height of the listbox) of the ListBox but the VerticalOffset(position of scrollbar from top) of the ListBox remains same. Now the problem I am facing is that the Vertical Offset is not absolute but relative to Scrollable Height. So the content being viewed till then will be changed basing on the new value of ScollableHeight.
I want to know the relation between them, so that I can do some math and set the VerticalOffset value.
I have added some dependency properties on VerticalOffset and ScrollableHeight through which I can get the events when any of them is changed. Trying to use ScrollIntoView for readjusting the Vertical Offset
Any suggestions or corrections are highly appreciated.
I am not able to find the calculation. But what can be done is listbox can be replaced by a scrollviewer which has itemsControl inside it. But the disadvantage of this is virtualisation is disabled, so will need to check on this.
But, overall this is going to give a bad experience on using such a UserControl in Listbox. So using templated list box given in WP7 toolkit is an option but it is gonna hang a bit since ListBox is not optimized for multi templated virtualization. So I started showing writing listbox item template in such a way it contains all the possible layouts which will enabled from a condition.
I have an application that displays wrapped text in a ScrollViewer that takes up a fixed height of the page. I set the HorizontalScrollBarVisibility to Disabled, and the VerticalScrollBarVisibility to Auto.
The usability problems I'm having are as follows:
Despite being set to Auto, if the content is smaller than the ScrollViewer, then the content can still scroll up and down, either scrolling past the end or hiding a portion of the text. I would like the ScrollViewer not to allow scrolling when the entire content fits inside its bounds. At the very least it should always snap the content back into view when you over-scroll.
Secondly, when the content does scroll, it sometimes gets stuck past the end and won't "snap back" from the over-scroll. For example, if the content fits fully in the ScrollViewer, and you drag your finger up or down on the text, the text will be obscured by the top or bottom of the ScrollViewer, and won't snap back. If however you drag your finger up starting from outside of the content of the ScrollViewer, it will snap back when you scroll past either end. I would like the "snap back" behavior to happen whether you drag on the content or outside of the content. Is that possible?
First issue: If your content isn't large enough to warrant the need for a scroll viewer don't put it in one. If the size of the content changes only enable the scrollbar when the volume of content warrants it.
Can you provide a way of reproducing the second issue.