I don't know whether this is intentional or not, but Infragistics has posted a database of all its bug reports on the new website. I downloaded all bug reports for the UltraWinGrid for the past six months -- there are 230 of them. Of these, only 43 are not marked "Closed" or "Duplicate." Of these, only 20 were created more than a month ago, and of these, only 6 are "In Review" while the remaining 14 are "Awaiting QA."

Assuming these statistics are accurate, Infragistics is doing a pretty good job of responding to bug reports, at least for the UltraWinGrid. The lesson learned is that if you are working on a time-critical project, you had better make sure that you have tested any dependency on assumed component behavior at least three or four months before the deadline for your project. 

Another good thing about the Infragistics grids is that the bug fix and new release QA process seems to be pretty good. Unlike the apparent case with some of the competition, most of the time hot fixes and new releases do not break existing code. 

The hard part in my experience has been getting an incident report resolved or converted to a bug report. One thing that has often happened instead is that the incident report gets stuck forever in a false "waiting for client action" state. Hopefully the new website design will make it easier for us to monitor this. The other thing that happens is that issues sometimes get defined as feature requests and not bugs.This can be a big problem.

Hello,

First of all, I want to apologize for the delayed answer - we wanted to investigate everything in detail. I do assure you that we understand the situation that you are in - all issues that you have reported are logged in our bug track system and most of them are already addressed by our development team. I will tackle the issues you have one by one and try to provide some relatively easy workarounds, so that you hopefully have tangible progress until we are ready with the hotfix.

1. UltraWebToolBar and tilde slash syntax for URLs ("~/"). You are absolutely correct - no matter if we calll it a bug or a missing feature, it is just not there and behaves differently from what you'd expect in a typical ASP.NET server control. This is logged in our tracking system and will be addressed very soon. Meanwhile, here is an workaround I can suggest - I do hope it is applicable in your case:

   <igtbar:UltraWebToolbar ID="UltraWebToolbar1" runat="server" BackgroundImage=""
        ImageDirectory="" ItemWidthDefault="">
        <Items>
            <igtbar:TBarButton DisabledImage="" HoverImage="" Image="" SelectedImage=""
                TargetURL="~/News.aspx" Text="Button1">
            </igtbar:TBarButton>
            <igtbar:TBarButton DisabledImage="" HoverImage="" Image="" SelectedImage=""
                TargetURL="~/News.aspx" Text="Button2">
            </igtbar:TBarButton>
            <igtbar:TBarButton DisabledImage="" HoverImage="" Image="" SelectedImage=""
                TargetURL="~/News.aspx" Text="Button3">
            </igtbar:TBarButton>
        </Items>
    </igtbar:UltraWebToolbar>
 
 
 protected override void OnPreRender(EventArgs e)
    {
        base.OnPreRender(e);
        foreach (Infragistics.WebUI.UltraWebToolbar.TBarButton button in UltraWebToolbar1.Items)
        {
            button.TargetURL = Page.ResolveClientUrl(button.TargetURL);
        }
    }

The idea is to override the OnPreRender method and use the Page.ResolveClientUrl ASP.NET method to map the "~/" syntax to the actual root relative URL you need.

2. Height 100% for UltraListBar. This one is very tricky - we also have logged this and there is a fix for this problem coming, however the problem here is general - UltraListBar in ListBar mode renders as HTML <table>, and 100% height for HTML tables is a very tricky topic and browsers have different opinion about that.

There are several approaches. The easiest is to remove the <DOCTYPE... > line from your ASPX file (automatically placed by VS.NET). IE6/7 with DOCTYPE set do not recognize table height in percentages correctly, so if you remove the DOCTYPE, everything should work fine. 

If you cannot remove the DOCTYPE, I can suggest the only workaround I can think of - adjust the size of the ListBar dynamically with javascript upon page loading.

    <script type="text/javascript">

        function setHeight(listBar)
        {
            listBar.Element.style.height = getWindowHeight() - 20 + "px"; // the -20 hardcoded value is to account for margins/paddings, if you have none, it is not needed
        }

        function getWindowHeight()
        {
            var viewportheight;

            // the more standards compliant browsers (mozilla/netscape/opera/IE7) use window.innerWidth and window.innerHeight
            if (typeof window.innerWidth != 'undefined')
            {
                viewportheight = window.innerHeight
            }

            // IE6 in standards compliant mode (i.e. with a valid doctype as the first line in the document)

            else if (typeof document.documentElement != 'undefined'
                         && typeof document.documentElement.clientWidth != 'undefined'
                         && document.documentElement.clientWidth != 0) {
                            viewportheight = document.documentElement.clientHeight
            }

            // older versions of IE

            else
            {
                viewportheight = document.getElementsByTagName('body')[0].clientHeight
            }

            return viewportheight;
        }
       
   
    </script>
   
    <iglbar:UltraWebListbar ID="UltraWebListbar1" runat="server" ViewType="Listbar">
        <ClientSideEvents InitializeListbar="setHeight" />

The idea is to hook the client-side IniitliazeListbar event and execute custom javascript logic that will set the height of the listbar to the height of the browser viewport. Again, very tricky, but I am afraid the only way to do it if you need the DOCTYPE.

3) UltraWebMenu offset when used fixed CSS positioning problem.

I am afrad I was not able to find a workaround for this one, but I see that this has been escalated today by our PM and has been just addressed (fixed). The fix will be awaiting QA approval and we will do our best to promote that to our next hotfix asap, or, if this is not possible, find other ways to send the fixed build to you.

The bug is logged and fixed under this ID

BR35546     Fixed CSS positioning causing the menu island to reposition to top

In conclusion, I'd like to thank you once again for escalating this problem and assure you that all issues you have reported have been logged and are already addressed (or we are working on them). Please, once again accept our apologies for this situation.

If you need anything - just let us know - we will gladly answer any questions you may have asap.