Classic Infragistics UltraWebGrid allows you to programmaticaly specify CSS styles for its various elements. For example code like this:
xmyGrid.DisplayLayout.HeaderStyleDefault.CssClass = "HeaderStyle"
xmyGrid.DisplayLayout.RowStyleDefault.CssClass = "RowStyle"
Would set style of grid header and rows via external CSS class. You would expect that simple defining classes like this:
.HeaderStyle { /* style definition goes here */ }
.RowStyle { /* style definition goes here */ }
should do the trick, but you may experience some unwanted, erratic behavior: styles getting lost, styles getting mixed up (row would get a header style and vise versa).
To fix this we should let grid know that header style should apply only to header row (THEAD/TH HTML elements) and row style applies only to rows with data (TBODY/TD elements). This is done via slight adjustments of the above CSS to point it to specific elements:
THEAD.HeaderStyle TR TH{ /* style definition goes here */ }
TBODY TR TD.RowStyle { /* style definition goes here */ }
This way there’s no confusion, styles apply exactly were they belong. Also you may need to set grids MergeStyles property to False and make each class fully define it’s element (including fonts, colors, backgrounds etc.)
If you’re still using classic Infragistics Controls and want to make them work in modern browsers, sometimes a little additional work is required. Hopefully this little trick will save you some time.
UltraWebGrid has a neat property TopItemSpacing, when set to Auto it automatically spreads top level menu items across the menu control, giving them nice spacing in between. Unfortunately this property seems to work in Internet Explorer only, in Firefox (and Chrome and etc.) it is ignored, rendering menu in Compact mode giving top level items crowded “too-close-for-comfort” look.
The solution is to take spacing in our own hands. Set TopItemSpacing to Compact and instead add right padding to TopLevelParentItemStyle and TopLevelLeafItemStyle elements of the menu. For example (from the markup point of view):
<TopLevelLeafItemStyle Cursor="Hand" Height="18px" BorderWidth="1px" Font-Size="8pt">
<Padding Right="6px" />
</TopLevelLeafItemStyle>
Actual pixel value of the padding is up to your particular scenario, but the final result is top level menu items will be nicely spaced both in IE and in Firefox.
This was one weird mystery. I have used ASP.NET’s method ClientScript.RegisterStartupScript countless times to inject client-side JavaScript into page’s markup from the server-side code and it always worked perfectly. This time I created a very basic page from scratch:
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>My Page</title>
<script type="text/javascript" src="script1.js" />
<script type="text/javascript" src="script2.js" />
<script type="text/javascript" src="script3.js" />
</head>
<body>
<form id="xfrmMain" runat="server">
</form>
</body>
</html>
And then injected client-side script into it:
ClientScript.RegisterStartupScript(Me.GetType, "JSCode", "ProcessData();", True)
where ProcessData() is function from one of the scripts, loaded in the HEAD tag. The script injected just fine, I got a beautiful insert at the bottom of the rendered page:
<script type="text/javascript">
//<![CDATA[
ProcessData();//]]>
</script>
The problem was – it didn’d do squat – the script did not execute. Why? Continue reading 'ClientScript.RegisterStartupScript: script injected, but not executed'»
Let’s say you have a Web page that displays “widgets” a small islands of information. And internally those widgets are IFRAME elements, whose source is loaded dynamically from the same server at runtime in client side JavaScript. So, you have a code similar to this:
var aIframes = document.getElementsByTagName('IFRAME');
for (var I = 0; I < aIframes.length; I++) {
aIframes[I].src = aIframes[I].getAttribute('originalURL')
}
This (oversimplified) code assumes that URL for IFRAME source already stored as a custom attribute ‘originalURL’ of IFRAME element (for example placed there by server-side code), but it can equally come from other sources. This approach is usually taken so IFRAMES can initially display a static page with “Please wait. Loading…” animation meanwhile dynamically loading real data – creates a better user experience.
The code loops thru all IFRAMEs setting their SRC attribute, displaying content, so you would see something like
It’s all well and good, but there’s a small problem. SRC of IFRAMEs is assigned in order of their appearance on the page and if URLs are pointing to the same server and one of the earlier IFRAMEs takes a long time to load – it will block the rest of the IFRAMEs from loading. Continue reading 'How to load IFRAMEs in order according to priority'»
If after upgrading to a new version of Infragistics NetAdvantage you suddenly found your WHDG sprouting an extra blank row on top:
most likely it’s because grid’s ItemCssClass property is used. In theory (at least according to ever so verbose documentation) it should define what grid’s cells look like. In practice it have no effect whatsoever. Or rather had no effect until upgrade (verified in version 2011.1, perhaps even earlier). Now if your CSS class used in this property contains HEIGHT attribute – a blank row of that height will be inserted on top of the grid.
Solution? Remove ItemCssClass property. It’s useless anyway.
This is the second post in saga titled Upgrading Infragistics Controls to a new version. Chances are that your WebDataMenu looks weird after upgrade to 2010+ version. In my case the menu had following options/features:
- It was a context popup menu, called on right mouse click
- Text of menu items was assigned dynamically at runtime in JavaScript Client code
After upgrading NetAdvantage from version 2009.2 to 2011.1 strange things started to happen. Text of the menu items was cut short, submenues appeared at wrong places it looked like something from a Dali’s painting.
Numerous experiments later I found out that the problem was with EnableScrolling property of the menu control. Setting it to False returned menu to realm of realism.
Upgrading 3rd party library to a new version is bound to have problems and Infragistics is no exception. In my case I was upgrading NetAdvantage for ASP.NET from version 2009.2 to to 20011.1 and right away WebHierarchicalDataGrid started to crash client-side. If ScriptManager was in debug mode I’d get error:
Microsoft JScript runtime error: Sys.ArgumentUndefinedException: Value cannot be undefined.Parameter name: type
With ScriptManager in Release mode it’d be:
Microsoft JScript runtime error: Object expected
But always in Sys.Component.Create – it looked like grid’s client-side scripts weren’t loading at all. After A LOT of digging I found out that the culprit was grid’s server-side Bands.Clear() method. When called, it caused client-side WHDG JavaScript not to load. When that method was commented – JavaScript errors disappeared. So until Infragistics comes out with a bug fix – if you experience similar problem, try to avoid Bands.Clear() method.
By default Internet Explorer 8 does not display blank cells in HTML tables (technically it does’t show borders around such cells) and visuals aren’t pretty. The solution below may not work for everybody, but I’d imagine will help in many cases:
Just set the table style to
border-collapse:collapse
Presto-chango! Missing borders now appear.
ASP.NET protects you pretty good when user tries to post a malicious content thru an entry form. With @page directive “ValidateRequest=true” (which is true by default) if anybody attempts to enter something like <script type=”text/javascript”>…nasty stuff here…</script> the page will throw HttpRequestValidationException exception: A potentially dangerous value was detected from the client…
But this does not work for some form elements, for example framework variables such as __EVENTVALIDATION or __VIEWSTATE over which user or developer do not have direct control. A maliciously crafted POST request can insert JavaScript into those elements which then can execute in user’s browser. Yes the page may crash because of invalid data, but JavaScript is still echoed to the client and gets executed. In this case ASP.NET needs a little help. Continue reading 'Prevent Cross Site Scripting thru hidden fields'»
I have been using WebHierarchicalDataGrid with manual load on demand bands with a pretty good success until I hit this snag.
The WHDG has correctly displayed HTML fields before, but this time a column with HTML data (an HREF link to be precise) is needed as one of the grid’s DataKeyFields to provide uniqueness of the row:
Continue reading 'WebHierarchicalDatagrid: Sys.ArgumentException: Cannot deserialize on Row Expand'»
Comments (0) 
Themocracy