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:
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.
In fact, if this is the attitude of the DS manager, I'm not surprised support is the way it is.
Cheers, 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
Jeffrey Vella said:I have aikido installed, and we tried to use the splitter a few weeks ago and it ended up randomly crashing internet explorer so we had to remove it. I did check the payload of that control briefly and i remember it being rather large, which is strange because it’s just a table with a couple lines of JavaScript to resize two cells? I will check out the rest of aikido when I get some time.
I have aikido installed, and we tried to use the splitter a few weeks ago and it ended up randomly crashing internet explorer so we had to remove it. I did check the payload of that control briefly and i remember it being rather large, which is strange because it’s just a table with a couple lines of JavaScript to resize two cells? I will check out the rest of aikido when I get some time.
Jeffrey:
Just to comment on this particular point, since the CTP release we have done a significant amount of work on reducing the JavaScript footprint of the Aikido controls. I think I read that the CTP shipped with something like a 500K javascript size for the core client side framework, and at last check we had reduced that something like 90K so we are working really hard to get that down.
I am however very concerned about the IE crash that you experienced. Is this something that you are able to reproduce? Can you post or send some code where you were experiencing the issue?
Devin
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.
jsalzman said: The product works, once you figure it out. I don't call myself an elite programmer, but I do know a lot. I also know how to read help files to get answers to questions about an API. However, the only help available for for these products (short of paying more for training) is difficult to follow. Some of the API references DON'T have examples. If they do, they only touch the basics and aren't well rounded. That leaves a programmer to themselves to figure things out most of the time. That can also explain the many unanswered questions in the Forums. Even the VB.NET help file from Microsoft has plenty of full and useful examples. WHAT'S SO HARD ABOUT WRITING A WALKTHROUGH TO COVER THE FINER DETAILS!?!?!
The product works, once you figure it out. I don't call myself an elite programmer, but I do know a lot. I also know how to read help files to get answers to questions about an API. However, the only help available for for these products (short of paying more for training) is difficult to follow. Some of the API references DON'T have examples. If they do, they only touch the basics and aren't well rounded. That leaves a programmer to themselves to figure things out most of the time. That can also explain the many unanswered questions in the Forums. Even the VB.NET help file from Microsoft has plenty of full and useful examples. WHAT'S SO HARD ABOUT WRITING A WALKTHROUGH TO COVER THE FINER DETAILS!?!?!
I echo this sentiment wholeheartledy. The NetAdvantage suite allows you to do things that would otherwise be impossible or take forever to implement oneself. However, the learning curve is very steep and training courses are only partially successful in this. It has taken me a lot of time to get to the level of understanding that I have to the UltraWebGrid. Much of this journey was also understanding how ASP.NET works, e.g. the page cycle, viewstate et al are crucial to understanding how the controls fit in.
So given the above, documentation is critical to the success of anybody using NetAdvantage. We've bleated on about this many times and it has improved, slightly. This is partially because I'm much more familiar to the suite and therefore need the documentation less - I can start to second guess your architechure and naming conventions.
But documentation for new users and new controls is still top of my list of things I wish were better. I suggested a while back that Infragistics commission a book. I was flattered when asked if I'd like to get involved but my knowledge of the entire suite is sketchy. I still think this is a good idea.
jsalzman said: Tech support is slow. Not all companies that purchase third party tools can afford much more than the tools themselves. If they didn't need the tools, they obviously can afford to pay in-house programmers to write them instead. In hindsight, I would not have recommended Infragistics tools to the department manager for purchase. We work on time constrained projects here. We cannot afford to wait days for responses to tech support questions.
Tech support is slow. Not all companies that purchase third party tools can afford much more than the tools themselves. If they didn't need the tools, they obviously can afford to pay in-house programmers to write them instead. In hindsight, I would not have recommended Infragistics tools to the department manager for purchase. We work on time constrained projects here. We cannot afford to wait days for responses to tech support questions.
Agreed. I came across a weird problem where the client side setValue call on the grid worked once and not again. I raised the job taking time to reduce the problem down to a simple standalone example. After several days, I got a reply back saying "Unable to repeat". This response is given far too easily I feel. I then sent a video showing the problem just to prove I wasn't lying.
In the end, I built a special VMware virtual machine with as little of the VS 2005 environment as needed to demonstrate the problem. This was sent in 250MB chunks via www.mailbigfile.com. Files sent via mailbigfile expire after 14 days and you also get a notification back when it's downloaded. No notification for about 7 days. Send another email saying "Hey guys, PLEASE download the VM as it'll expire soon".
It was finally downloaded and Infragistics reproduced the fault (not hard as you had an entire VM...) but ONE MONTH elapsed between the initial report and the response "Yes, it's a fault". Okay, so there was xmas in the way so knock off one week.
On 22nd Jan I got an email with a suggested workaround but I'm afraid this had to be resolved before then and I'd recoded the page to use a different control.
This might be an extreme weird error but actually with the complexity of the controls, I think they are going to be weird and esoteric a lot of the time.
BTW - the bug only occurs when running with UK regional settings which explains why the non-UK technical support person was unable to repeat using the project alone.
jsalzman said: because I finally figured out the problem myself. It turned out to be a "potential" bug using dual monitors. I usually get "It worked for us" responses to my help requests, nothing more, even handing off some examples. Sometimes it's not
because I finally figured out the problem myself. It turned out to be a "potential" bug using dual monitors. I usually get "It worked for us" responses to my help requests, nothing more, even handing off some examples. Sometimes it's not
Spooky - just what I've just said.
jsalzman said: easy sending examples because we are data intensive here. Lots of our applications connect to our databases. That's tough to mimic with 100% accuracy elsewhere. Instead, I try to be as descriptive as I can with the problem. If that's not enough to resolve our tech support issues, it falls on 'us', the customer, to have to pay for the man hours to create a
easy sending examples because we are data intensive here. Lots of our applications connect to our databases. That's tough to mimic with 100% accuracy elsewhere. Instead, I try to be as descriptive as I can with the problem. If that's not enough to resolve our tech support issues, it falls on 'us', the customer, to have to pay for the man hours to create a
Whilst the above I had to go through to get them to see the bug for real seems OTT, it might be the only way in some cases. I appreciate the effort of building a VM is a lot but now I've got it, I'm going to keep it just in case something else crops up.
jsalzman said: So, as I stand with Infragistics stuff. Well, we paid for it already and we got our last free update. We'll drag through it as best as we can. Between myself and the other programmers here, we'll soon figure out what works and what doesn't. But we will most likely be on the lookout for other control vendors when we need to, unless some miracle of tech support manifests itself.
So, as I stand with Infragistics stuff. Well, we paid for it already and we got our last free update. We'll drag through it as best as we can. Between myself and the other programmers here, we'll soon figure out what works and what doesn't. But we will most likely be on the lookout for other control vendors when we need to, unless some miracle of tech support manifests itself.
I have thought the same myself many times but I've stuck with it and at the very end, I'm glad I did. To implement the functionality we get "for free" with just the grid is worth it. I toyed with writing it myself but gave up...
The NetAdvantage suite *does* work but there are some parts of it which don't work very well or are idiosyncratic. The documentation still needs a lot of work.
We don't want just a reference guide - we need that all important "This is how the grid works"...