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
266
Infragistics controls frustratingly slow & heavy
posted

The only explanation i can come up with is that it's more profitable to cheaply hack together new controls and start selling them than to take the time to do things properly. I have worked with infragistics for years, i have been to your training, i have used and skinned almost all of your controls and im just plain frustrated with it all. 

My frustrations boil down to three things:

  1. Web pages loaded with lots of infragistics controls get bogged down and slow because of the weight. One here and there seems to be fine but the rule of thumb seems to be 'use as sparingly as possible' which isnt the way it should be.

  2. Infragistics controls crashing my Visual Studio IDE, or controls losing state, overwriting or losing its settings when maniulated with the wizards and custom property windows. And just being generally buggy and behaving weirdly.

  3. Controls being notoriously difficult to style, and by style i dont mean just changing some font colors and basic stuff. In my opinion controls at this enterprise level should be able to skinned more easily adjust to custom designs.

To get a very basic idea of the bloat issue take a grid control, bind it with a basic data on an otherwise blank page and view the resulting page source and you'll see what i mean, check out the page weight / file size from html and in fact do it with any controls. There's so much convoluded, unneeded and downright dirty code its dissapointing. Things like tables repeatedly nested inside each cell. I realise that there are scenarios where this is the only option but why not remove the overheads when those features aren't being used?

Maybe with the increase in consumer internet bandwidth its been taken as free reign to not optimise and streamline. Maybe i get the worst end of the problems because i work with UI design and skinning controls.


Parents Reply
  • 45049
    posted in reply to Rob

    informed_direct said:
    PS. Could Infragistics set-up an FTP or sign up to www.mailbigfile.com themselves (it's not that expensive) or actually write (using your controls <grin>) a web upload service that's not size limited.

    While Infragisitcs recognizes that there a few circumstances when sending large files to Developer Support may be helpful, in the vast majority of cases the sending of large files either does not help or sometimes slows down resolution of an issue.  Infragistics is a component vendor, not an application developer, so we usually cannot debug large applications.  Usually, sending an entire virtual machine would involve sending the whole application with it.  Even in the uncommon cases where such things are helpful, if it turns out that a change to our products' code is needed, we still need an isolated sample project that duplicates the problem so that we can confirm we've fixed it.  These are the primary reasons why Developer Support works with small, isolated sample projects - both providing them to show what we've tested with, and requesting them to see what our customers are testing with.

    In the case you refer to above, you had a small, isolated sample project that worked fine on our systems but did not on your VM.  The "key point" was a culture setting on the VM you were using, which differed from the one Developer Support was testing with.  This is a very uncommon cause for the kinds of problems normally reported to us, and is why the issue took so long to identify; even when able to reproduce the problem using your VM, it took a long time to find out what we could change on our systems to have the same problem occur.  It would likely have taken roughly as long (possibly shorter, possibly longer) to compare our system settings to yours without the exchange of the VM.

    Since sending large files, whether applications or virtual machines, is only very rarely of any value, we can't justify the cost to sign up for a file upload service, to create our own file upload service, or to set up an FTP site.

    We are, however, working on better ways for our customers to send files to us, and for us to provide files to our customers.  These changes are part of updates we're working on to our internal Developer Support systems.  I don't yet have better details or a timeframe that I can share, but I do expect these changes to be helpful to both us and to customers.

    An "it worked for us" response from Developer Support should include information about what the Developer Support Engineer attempted.  In most cases, this will include the sample project we tested with.  The idea here is so that you can compare what you're doing to what the Developer Support Engineer did, find out what's different, and provide us with that information.  The vast majority of the time, this gives us enough information to reproduce and further investigate the behavior you're reporting, and the rest of the time, it usually gives us further questions we can ask to better hone in on the cause.  Sometimes we can theorize on a cause, but sometimes we can't.

    As Darrell mentioned previously, if anyone is encountering problems when working with Developer Support, please send your feedback to me via email so that I can investigate the situation.  You can reach me at:  dsmanager@infragistics.com

Children