I'm trying to get scrollbars working with the web browser control. However, as I'll be using it to display a message for a custom messagebox, I don't want the scrollbar to appear even if its not needed - as it seems to do by default. To circumvent this I decided to disable scrollbars on the control and instead use scrollbars on another control like a Panel. This way they'll only appear when the contents of the browser page is too big to fit.
This hasn't worked out too well, though I've read quite a few posts, even on StackOverflow, where this seems to be a valid solution. One example is when I tried using the solution here:
Scrolling problem with a WebBrowser control contained in a Panel control
It seems as though if Scrollbars are disabled for the web browser, it won't let the panel use scrollbars either. This seemed to be the case when testing in design mode. To overcome this I tried adding a picture box behind the web browser inside the panel; it worked when in design mode (resizing the picture box and web browser would cause the panel to enable its scrollbars), but didn't work during runtime (I added code to have the picture box change to the size of the web browser control - which itself is always resized to fit the size of the scrollable contents).
I also tried programmatically enabling and disabling the web browser's scrollbars based on if the ScrollableRectangle size was bigger than the size of the control. This theoretically would be fine, except it seems to clear all text within the control any time the ScrollbarsEnabled property is changed - and thus is changed back to having no scrollbars.
I'm doing this with the following code, called effectively whenever a key is pressed in the control:
if (Output.Document.Body != null)
{
if (Output.Document.Body.ScrollRectangle.Size.Height > Output.Size.Height
|| Output.Document.Body.ScrollRectangle.Size.Width > Output.Size.Width)
Output.ScrollBarsEnabled = true;
else
Output.ScrollBarsEnabled = false;
}
else
Output.ScrollBarsEnabled = false;
It's also important to note that I also need a solution for the HTML editor which will be used within the app, so ideally any solution would not rely on a page load event etc... as these do not seem to trigger when the web browser has design mode set to on (which is needed for it to work as an HTML editor). However, in this particular situation I can fall back on enabling the default scrollbars if there's no better solution.
EDIT: To be clear, I am not talking about any scrollbars within the HTML content - that is of no concern as the HTML is simply being used to allow for flexible formatting of text. I'm talking only about the scrollbar of the browser control itself.
Any help much appreciated. Thanks!
I ended up finding a solution to this some time ago now, but forgot to post here. Basically what I did was first enable the scrollbars by default so they will work, although always appear. Then I created a panel control and sized it over the top of the inactive scrollbar that appears on the right of the web browser control.
Next I changed the anchors of the scroll bar panel so that the top, bottom, and right sides would always snap into the size of the form, and hence the size of the browser control as all edges of it too are anchored.
Then I added some code that checked the ScrollRectangle size and compared it with that of the browser, if it turned out to be larger in height or width, I then made the cover panel not visible, but otherwise left it in place.
Here's the relevant code snippets:
//If still bigger, set scrollbars:
if ((Output.Document.Body.ScrollRectangle.Size.Height > Output.Size.Height) ||
Output.Document.Body.ScrollRectangle.Size.Width > Output.Size.Width)
{
ScrollPanel.Visible = false;
ScrollPanel.Enabled = false;
}
Hope this helps someone else in future, took a few different methods before I found one that worked well enough.
I've decided to up Sheng's answer (when I get enough reputation) as, firstly he was the only person to response, and secondly, his information helped me when I was contemplating the use of some kind of invocation to try and enable the scrollbars during runtime. Though I found my solution simpler and just as effective.
That's too late. IDocHostUIHandler.GetHostInfo is called when the webbrowser is created, and the WebBrowser's implementation sets DOCHOSTUIFLAG_SCROLL_NO or the DOCHOSTUIFLAG_FLAT_SCROLLBAR flag based on the value of its ScrollBarsEnabled property.
I suggest you to set ScrollBarsEnabled to false before creating the Webbrowser control's window.
If you don't want the scrollbar of a particular element, such as body, div or textarea, to appear, you can set their styles to overflow='hidden' or use scrolling properties specific to the elements such as doc.Body.SetAttribute("scroll","no").
Related
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'm working on a UWP app and I'm having some trouble with the visual states of some UI controls, specifically with buttons and toggle buttons.
Basically, I'd like the borders that become visible when you press the TAB key (to navigate using the keyboard) to have the same ZIndex of the rest of the control, ie. if part of the control is covered, they should be covered too in the same way. But, it looks like these borders are always displayed on top of the UI, no matter what. Here's a screen:
You can see the border going over the rest of the UI, while the rest of that toggle button is correctly covered. The same happens for buttons as well (not only toggle buttons), see here:
I've looked at the template for these controls, but I couldn't find anything related to these specific borders, nor to anything like an explicit Canvas.ZIndex setting or something like that.
I guess this behavior is on purpose, but is there a way to change this and make those borders behave like the rest of the UI?
Thanks!
EDIT: here you can see how a reveal highlight effect is correctly covered by the shadow and the other UI elements on the right, but the TAB border ignores that and is displayed on top of them.
I have noticed similar behavior was previously present in the Start menu as well (although it wasn't with focus border, but with the reveal effect clearly "continuing" into the cut-off portion of the button.
One workaround that comes to mind is to observe the state of the SplitView and when it is closed to actually change the width of the buttons (for example via a StateTrigger). This way the button's area will no longer be "hidden" and the focus border will work properly, as the buttons will end where they should.
I'm needing some assistance with what I can tell a vendor developing a form in an application I don't have the source to. We've found a bug with one of their large Winforms where if it's opened in an RDP session at 1024x768, the bottom 250px or so of the form which is ~1000px high is unreachable.
They're being difficult about saying there's no solution which I know to be nonsense, but I don't have a Visual Studio environment presently set up to build a proof of concept to test for myself and then show them otherwise.
From what I can tell from other StackOverflow questions and MSDN documentation pages, something like the following should resolve the problem so the form will auto-size to the maximum displayable height then put a vertical scrollbar in to allow viewing the bottom part of the form. Will the following achieve my goal?
public MyTallForm()
{
InitializeComponent();
this.AutoScroll = true
this.AutoSize = true
}
AutoSize responds to change in controls inside the form by growing & shrinking the form as needed.
AutoScroll responds to change in controls inside the form by displaying/hiding the scrollbars.
Thus, AutoScroll won't be activated if AutoSize is active since the form is always large enough. If the problem is from too small display resolution, you'll want AutoScroll.
If the form kept open between RDP sessions, you might need to subscribe to DisplaySettingsChanged to be aware of resolution changes, and either simply Maximize (not sure if it's already maximized, toggling to Minimized and back to Maximized perhaps?) or use GetWorkingArea if you need detailed size.
Set AutoScroll = True and AutoScaleMode to Dpi In Form Properties
Hope it helps.
I'm experiencing difficulty with a custom-made User Control, and my searching on Stack Overflow, MSDN, and Google didn't pop up any troubles quite like the one I'm experiencing.
I have a very simple User Control: It's a label, a text box, and a button, with a SaveFileDialog and a FolderSelectDialog available. The text box and button are anchored Left,Right and Right respectively, with the intent that if the control is resized larger, the text box will enlarge to fill the gap, and the button will stay on the right edge of the control.
The problem I am encountering is that when the control is enlarged, the area to the right of the default width of the control becomes blank space when the project is built and run. The pictures here will illustrate what I mean:
In editor:
Running:
The control is smallish in its design window, but when I add it to a form and widen it, it behaves as intended. However, when I run the form the control was added to, half the control isn't visible.
I suspect that I'm overlooking something fairly straightforward, but I wasn't able to find anything addressing this point in my search. Help would be much appreciated.
My guess is that there is a panel or something that is added to your control and will be brought to front somehow runtime.
from property window's top there's a combo from which you can select all the controls in your User Control.
check if all the controls are what you want.
if you find that panel or anything delete it :)
EDIT:
alright this was not your problem.
now I can only assume that you have set some manual sizes to your user control, i.e. in its constructor. in that case designer will show the correct size of you user control,
now some other place in your code, you have set the user controls size manually again. if the layout is suspended and size changes, I think that the anchored controls' size will not change automatically.
if this is your problem, it is probably hard to find.
Finishing up a register form in a C# application and I noticed with the panel if I enable AutoScroll and then have a textbox that is below the scroll and click on it it jumps all the way back up to the top. Is there a way to fix this with some code or is it a propriety?
It's a little difficult for me to explain it in words, so here's a short video that shows the behavior.
I have had the same problem. I fixed it with this code in my panel:
protected override Point ScrollToControl(Control activeControl)
{
return this.AutoScrollPosition;
}
I had this exact problem. I had to remove the docking from my panels on the form and this fixed the problem.
Since apparently no one has seen this behavior before and could provide a quick answer, I opened up Visual Studio to try and reproduce what you describe.
I created a new WinForms project with a GroupBox containing a Panel whose AutoScroll property is set to "True". Then, I added two new GroupBox controls inside of the Panel, each containing two TextBox controls. The first embedded GroupBox is at the top of the form, entirely visible at startup; the second embedded GroupBox is at the bottom where it must be scrolled into view. This is equivalent to the design/layout that you have as best I can tell from your description and video.
However, when I run the project, scroll down to the second embedded GroupBox and select one of the TextBox controls that it contains, it performs exactly as expected. The TextBox control that I clicked on gets the focus, without scrolling the entire panel back up to the top. I can't seem to reproduce what you're seeing. If you could either tell me what I've done wrong in designing my test sample or post the smallest sample project needed to recreate the behavior you're experiencing, I might be able to help.
Otherwise, here are a few suggestions of things to investigate:
The tab order of the objects on your form. This really shouldn't be causing the behavior described because clicking on a control should set the focus to that control, regardless of its position in the tab order, and jumbling up the tab order multiple times in my sample project still doesn't appear to have the same effect. But I suppose it's worth a try anyway. In Design Mode, go to your "View" menu, and click "Tab Order". All of the controls that you can set the tab order for will have a little colored box at their top-left corner, indicating their tab order in each container. To set the tab order, click once on each of the controls in the natural order you want them to be focused.
Scour your code for any <Control>.Focus or <Control.Select> statements. Make sure that you don't have any validation code that's altering the tab order in any way during run-time. This could be causing focus to jump back to a control located near the top of your Panel, forcing it to auto-scroll to the new location.
Try to reproduce the behavior in a brand new, clean project. Ideally, create a new project in Visual Studio and lay out the controls the exact same way you have them in the project with which you're experiencing difficulties. This is the same thing I did, partly because I don't have your particular project to work with, and also because this is the best way to troubleshoot particularly tricky behavior. It's more likely there is some quirk to your design or source code that's causing this behavior, rather than some kind of bug in the controls themselves. But either way, this will let you know exactly where the problem is occurring, which will get you that much closer to a solution.
You can use TableLayoutPanel" instead of "Panel" to avoid scrollbar change its position.