Reputation: 1609
I'm experiencing a very strange behavior that I can't really reproduce except in my main application: I use an Infragistics WebSplitter component that splits the page into two panes. On the right side of the pane, there are some grids (aligned inside HTML tables, and sometimes without); if the grid Width
is set to 100%
, the grid takes the whole width of the splitter pane as desired. The same goes for any <table>
with width:100%
set.
But: any asp:ListBox
or asp:TextBox
that uses Width="100%"
is somehow capped at a certain fixed amount. That is, the control scales if I decrease the splitter pane size dynamically, and increases again, but then caps out again at the same amount (which seems arbitrary, but is always the same). It also doesn't matter if I set the Width
attribute or do it via css (width: 100% !important;
). The same goes for the editors inside the grid; if I edit a cell, a text box opens (happens with the ASP.NET TextBox variant of the Infragistics grid, but also with their own editor provider control) that has the same width as the current column width. But if I increase the column size, it is capped out at the same amount.
It is important to note that the amount also stays the same no matter how/where I align the control. If I, e.g., center it horizontally inside the pane, the size is still at the same cap, but it is centered correctly. Setting the width to a fixed amount instead of 100%
, but greater than the visual cap, still makes it cap out.
I apologize for the vague formulation and lack of code, but I'm at a loss here since I cannot reproduce it so far; so I just ask and hope that anyone has encountered a similar issue at some point and may push me in the right direction to look.
Edit: It seems only form controls are affected. For example, asp:Label
with Width="100%"
works fine as well, but asp:TextBox, asp:ListBox
don't. For some reason, asp:DetailsView
does work, but I assume it's because it is using an HTML table
underneath.
Upvotes: 1
Views: 686
Reputation: 1609
It was indeed a stupid CSS restriction that I didn't see in the first place. In the Visual Studio 2013 template for an ASP.NET application with a master page, a Site.css
file is references which has code similar to the following:
input,
select,
textarea
{
max-width: 280px;
}
Which makes for that strange behaviour (well, not really strange per se, but it occurred to me as strange because I encountered the issue initially only in edit fields of the Infragistics grids, since there were no other input controls of that width anywhere).
Upvotes: 1