George: <additional commentary> We are not sitting around waiting for Adobe to hand us a fix. We are doing what needs to be done to get the applications finished.
We like Flex, but if the level of effort to work around bugs becomes so time consuming as to make it easier or faster to switch to something less buggy, what do you think we should do? Personally I think that my comments, if internalized by Adobe, can be beneficial to them as well as us developers. Regarding this specific issue, I suspect that the folks at Adobe took one look at the problem, determined that it was a problem (which was good), but then made an internal decision to postpone anyone looking for the solution until after the new release comes out of beta. I also believe that because of the discussion here (specifically comments by Alex Haruri), and in another thread that it was determined to be more of an enhancement than a bug fix, which pushes it way down the priority list. In summary I think we do a disservice to ourselves, and to Adobe if we "go silently into the good night..." by working around problems and not holding Adobe's feet to the fire to fix problems in their code. </additional commentary> Paul --- In flexcoders@yahoogroups.com, George <[EMAIL PROTECTED]> wrote: > > [personal thoughts] > Working on Flex projects you have to overcome some 'bug' troubles > yourself. Adobe developers couldn't has enough time to help everybody to > find solutions, they have to work for tasks depending on priority like > all software development teams. > > Nothing can be perfect we have to trade-off. Performance can be a > problem, but if there's a performance problem, you can still change your > interface design to make it more acceptable for end users. > > Your developers are lucky to work with you even don't have to waste time > for sorting functions. I have to find trade-off solutions more than > these small tasks, even have to think about how to change interface, and > defend for myself. End users and bosses wouldn't care where's the > problem, what they know is if there's a problem, it's my problem, I have > to fix it or make it better at least. > > For SDK code itself, I think we should let Adobe developers to judge > whether it's a simple fix or not. They could have reasons we wouldn't know. > > George > > > > aceoohay wrote: > > > > > > The good news is I believe that the folks at Adobe are convinced this > > is a bug. > > > > The bad news is I was told that they aren't going to fix it anytime > > soon, what with the new release coming out and the fact that there is > > an "easy" workaround and all. > > > > <opinion> > > It is my opinion, after looking at the code that generates the error, > > it would be a relatively simple fix. I believe that all that would be > > needed is in the routine that determines the data type to sort on it > > should ignore nulls. As it loops through the column to find the data > > type should it find no non-null elements, it doesn't need to sort > > anything. > > > > The only performance impact would be on columns that contain lots of > > nulls, but I would rather have my users wait a few milliseconds > > rather than get an error, or have my developers waste time adding > > sort handlers for each column in each datagrid. Also I am sure that > > the sort handlers have a substantial performance impact at runtime. > > > > What I am trying to say is I believe that Adobe has made a mistake in > > offloading a significant amount of work onto developers, and has a > > poorer product, when with a small effort they can solve the problem. > > </opinion> > > > > Paul > > >
