Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
95
How not to Define Service
posted

It is now 4:18am on the West Coast and I have spent most of the evening and morning stripping the Infragistics controls out of my application due to failures, a deadline approaching in less than 2 weeks for delivery of the product and a client who repeatedly reams my butt over the poor service Infragistics is providing.  I have used 3 controls so far which has resulted in 5 support requests and 3 bugs stopping my project dead in its tracks.  I want and DEMAND my money back.

So far, out of the 3 controls I have used, I have had problems with all 3 of them rendering them pretty useless to me.  The toolbar control won't take a ~ in the target URL so I have to change the references everytime I upload to the host (yet every other property such as all the image urls do take the tilde - you say this isn’t a bug but a feature request), the menu control won't take fixed positioning which is “in development” (this is not a problem in the default asp menu control) and it also won’t save changes when placed in an ascx file, instead it usually simply discards them when you close out of the designer and close the control.  So I have to make the changes manually (where I know the syntax) or keep trying them until they stick.It is nice somebody got back to me on the list bar. As far as tech support, on the fixed positioning problem, you sent me back a demo, showing me it would work that didn’t even use fixed positioning, and thus was not only worthless but almost comical.  On the listbar problem failing at 100% height we are now discussing, your tech support sent me back and example showing me it worked, using explorer view instead of listbar view (which didn’t have the failure).  So when I list steps to reproduce you’re not following them costing me further delays.  I send examples with EVERY case. Your controls were purchased (updated) for a web production that is due out with a nationwide magazine ad by September 1.  There is no pulling the ad at this point.  The listbar and menu problems are causing big production delays.  The toolbar is a nuisance but not stopping production.  I am now working twice as hard with your controls and spending the rest of my time in workaround strategy or on your site looking for status changes.  The client is in total panic and it has taken you guys a week to get in touch with me. I spoke to customer service last week and was told someone from development would give me a call.  No call.  No email.  I followed up by calling sales with no response from anyone.   I had to call customer service again today and harass you guys to get THIS email. I hope you realize I have been using your controls for years.  What I was buying with your controls wasn’t software, it was a service, that was intended to make my development life easier. I can buy control sets anywhere.  It has been your service and the quality of your product that has kept me with your company. It appears that it is time for me to re-evaluate which control set I am willing to stake my business reputation on.  I am truly frightened to use any of the more sophisticated controls in the collection I purchased.

 

  • 28464
    posted

    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. 

  • 1467
    posted

    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.