I've been working with a user on this issue and since it involves CSS and IE (two things I try not to be familiar with), I figured I'd blog it to see if one of my readers can help.
Here is the gist of the problem. The user has a cfgrid, ajax-based (well, the new fancy HTML grid, in this demo it won't use HTTP to load it's data), that is editable. In IE something odd happens.
When you click and edit a cell, the cell goes blank. But if you click on another row, you can see your data. If you click back, and try to type, your data is there, so you don't lose anything. When you submit, the mods are there as well.
Here are some screen shots. First, the table before anything is done:

Now here it is, blank, right after I finished modifying it:

And here is a shot with me selecting another row. You can see now that the data is there:

My guess is that this has to be a simple CSS/IE conflict. Anyone else run into it? Anyone have a possible solution?
Comment 1 written by Dave Byers on 5 August 2008, at 2:20 PM
Comment 2 written by Andy Sandefer on 5 August 2008, at 2:21 PM
Comment 3 written by Dave Phipps on 5 August 2008, at 4:07 PM
If you need any pointers/example code just give me a yell.
Comment 4 written by Jared Shields on 5 August 2008, at 4:39 PM
SOLUTION:
Open the EXT-ALL.CSS file (traditionally located at /CFIDE/SCRIPTS/AJAX/RESOURCES\EXT\CSS/)
Search the file for "//". You should find roughly 6 lines that look similar to this "//color: white;". Clearly somebody mixed up their comment syntax and incorrectly commented those lines out; thereby, NOT commenting them out.
Go ahead and change the prefix on the line from "//" to "/*" and end the line with "*/".
Refresh and your problem should be solved. :-)
Note, this problem was NOT resolved by 8.0.1 so everyone will need to update this file.
Cheers.
Comment 5 written by Christian Gurney on 5 August 2008, at 5:42 PM
Great sleuthing, BTW.
Comment 6 written by Mat Evans on 6 August 2008, at 3:38 AM
i've been looking at the problem for about a year!!!
there's a couple of other little caveats with the grid too, mostly all solvable with css.
Mat
Comment 7 written by Paul on 6 August 2008, at 9:44 AM
BTW, I believe you need to surround the offending lines with /* */ as follows:
.x-grid-row-selected td, .x-grid-locked .x-grid-row-selected td{
/*color: white;*/
}
.x-grid-row-selected span, .x-grid-row-selected b, .x-grid-row-selected div, .x-grid-row-selected strong, .x-grid-row-selected i{
/*color: white !important;*/
}
.x-grid-row-selected .x-grid-cell-text{
/*color: white;*/
}
.x-grid-cell-selected{
background-color: #316ac5 !important;
/*color: white;*/
}
.x-grid-cell-selected span{
/*color: white !important;*/
}
.x-grid-cell-selected .x-grid-cell-text{
/* color: white;*/
Comment 8 written by Jared Shields on 6 August 2008, at 10:42 AM
Comment 9 written by Brian on 6 August 2008, at 3:05 PM
Comment 10 written by Jared Shields on 6 August 2008, at 7:50 PM
The installations that I've confirmed it on are 8.0 and 8.0.1 (That was upgraded).
Can anyone else confirm this?
Comment 11 written by Dave DuPlantis on 7 August 2008, at 8:05 AM
Comment 12 written by Raymond Camden on 7 August 2008, at 8:29 AM
Comment 13 written by Brian on 7 August 2008, at 10:40 AM
Comment 14 written by Brian on 7 August 2008, at 10:51 AM
//color: white;
but if I use Dreamweaver to follow the link in my code, which I did before, I get:
background-color:#316ac5 !important;color:white;
Not sure how that translated.
Comment 15 written by Raymond Camden on 7 August 2008, at 12:12 PM
Comment 16 written by Jared Shields on 7 August 2008, at 6:41 PM
Comment 17 written by Ryan on 13 August 2008, at 9:54 PM
Comment 18 written by Steve on 21 August 2008, at 2:04 PM
Comment 19 written by Paul on 25 August 2008, at 3:50 PM
Comment 20 written by Brian on 25 August 2008, at 4:03 PM
Comment 21 written by Paul on 25 August 2008, at 4:14 PM
Comment 22 written by Brian on 25 August 2008, at 4:26 PM
Comment 23 written by Raymond Camden on 25 August 2008, at 10:33 PM
My general answer is - if the built in ajax ui stuff is not working well, then I'd probably not use it. Remember that the built in Ajax UI stuff is simply wrappers to other libraries. Adobe did their best to try to make it as easy as possible, but in doing so, also had to cut some corners. This I think is fair. But it means that if the out of the box UI stuff doesn't work well, then you should consider rolling your own.
Doing so does NOT mean you are turning your back on CF8 and Ajax. There are still plenty of NON-UI Ajax things that you can - and should - continue to use.
Does that make sense? Not trying to pass the buck here of course.
Comment 24 written by joe on 26 August 2008, at 8:48 AM
Comment 25 written by Raymond Camden on 26 August 2008, at 8:55 AM
CF - like every other software product in the world - has bugs. Nothing will change that. If you follow the procedure to report bugs to them to help them fix it however it will lead to them being able to fix it.
I have - from time to time - recommend folks not using the Ajax UI stuff if they have more advanced needs. This has nothing to do with any bugs. More it's the understanding that the tags CF built can't cover each and every possible use case. That would be impossible. For folks who are new to Ajax, the tags in CF8 can be a godsend. But for those who are more comfortable with other libraries, ike jQuery UI, then it may make more sense to use them instead.
Comment 26 written by Paul on 26 August 2008, at 12:07 PM
<cftimer type="debug" label="50 Grid Check">
<cfform name="test">
<cfoutput>
<cfloop from="1" to="50" index="i">
<cflayout type="vbox" name="layout#i#" style="width:100%; height:100%; display:inline;" >
<cflayoutarea title="User Profile" selected="true" name="userprofile#i#"style="height:80%; width:100%; display:inline;" >
<cfgrid format="html" bind="cfc:customer.getUserInfo({cfgridpage},{cfgridpagesize},{cfgridsortcolumn},{cfgridsortdirection},'#i#')" onChange="cfc:customer.updateUser({cfgridaction},{cfgridrow},{cfgridchanged},'#i#')" pageSize="1" bindOnLoad="false" width="650" autowidth="false" name="userprofile#i#" >
<CFGRIDCOLUMN NAME="UserID" HEADER="User ID" WIDTH="1" display="False">
<CFGRIDCOLUMN NAME="duReportedUserID" HEADER="ID" WIDTH="35" >
<CFGRIDCOLUMN NAME="duFirstName" HEADER="First Name" WIDTH="65" textcolor="black">
<CFGRIDCOLUMN NAME="duLastName" HEADER="Last Name" WIDTH="65"/>
<CFGRIDCOLUMN NAME="duTelNo" HEADER="Phone Number" WIDTH="65"/>
<CFGRIDCOLUMN NAME="duEmail" HEADER="EMail" WIDTH="65"/>
</cfgrid>
</cflayoutarea>
</cflayout>
</cfloop>
</cfoutput>
</cfform>
</cftimer>
On my server the debug says [280ms] 50 Grid Check
But the page actually takes minutes to load, IE or FireFox.
Take out the grids and it loads in seconds. So this does seem to be a performance problem with the grid itself.
Comment 27 written by Raymond Camden on 26 August 2008, at 12:12 PM
However - I'd say 50 grids on a page being slow isn't a bug. Just like putting 50 large JPGs on a page would slow it down, I'd say overuse of _any_ UI item would cause a slow down. Now it you saw significant slowdown with 5 or less grids, which is a much more reasonable #, then I'd definitely say we have a problem.
I noticed in your earlier comment you mentioned 2 grids slowing the page down to a crawl. What is the total time to load when using 2 grids?
Comment 28 written by Raymond Camden on 26 August 2008, at 12:22 PM
Empty Cache: 591K (css+js+cs+html+image)
Primed Cache: 16.1K
So the non-primed cache is large. This represents all the stuff loaded to support the ajax items. This is large, yes. You can get smaller #s if you use jquery. Again though folks the idea here is trade offs. You get the convenience of ease of use but the trade off is the impact on the initial download.
Comment 29 written by Paul on 26 August 2008, at 12:58 PM
Comment 30 written by sneha on 12 September 2008, at 7:07 PM
For eg:
<cfgrid format="html" name="campaignGrid"
bind="url:http://mysite/cfc/cfcname?method=....etc"
onChange="url:http://mysite/cfc/cfcname?method=editData&grid...={cfgridaction}&gridrow={cfgridrow}&gridchanged={cfgridchanged}"
Although url in bind works...the onChange doesn't seem to work this way.
I had onchange="cfc:cfc.cfcname...." before but some prob with my cfc path that i couldn't resolve. So i need to get this working this way. Can someone point out whats wrong.
Comment 31 written by Raymond Camden on 13 September 2008, at 1:24 PM
Comment 32 written by sneha on 13 September 2008, at 2:41 PM
onChange="url://cfc/cfcname.cfc?method=editData&gridaction={cfgridaction}&gridrow={cfgridrow}&gridchanged={cfgridchanged}"
But didn't seem to help.
After double clicking & editing the cell i do see the red indicator in the corner of the cell, but when page is refreshed, i don't see the change anymore. I don't get any errors either to figure out where the problem is.
Here is the editData fn from the cfc:
<cffunction name="editData" access="remote" output="false">
<cfif isStruct(gridrow) and isStruct(gridchanged)>
<cfif gridaction eq "U">
<cfset colname=structkeylist(gridchanged)>
<cfset value=structfind(gridchanged,#colname#)>
<cfquery name="edit">
update [table]
<cfif isNumeric(value)>
set #colname# = #value#
<cfelse>
set #colname# = '#value#'
</cfif>
where campaignID = '#gridrow.campaignID#'
</cfquery>
</cfif><!---end <cfif gridaction eq "U"> --->
</cfif><!---end <cfif isStruct(gridrow) and isStruct(gridchanged)> --->
</cffunction>
Like how i had to include returnFormat=json in the bind url, should the format be specified in the onChange url too?
Comment 33 written by Raymond Camden on 13 September 2008, at 5:53 PM
So I'd assume you want
url:/path/to/CFC
or
url:cfcinsamefolder.cfc
To include the returnformat, just add it as a query parameter.
url:my.cfc?method=dosomething&returnformat=json
Comment 34 written by sneha on 13 September 2008, at 6:32 PM
I tried url:/cfc/cfcname.cfc?method=editData&gridaction={cfgridaction}&gridrow={cfgridrow}&gridchanged={cfgridchanged}&returnFormat=json
I also moved cfc to same folder as this page & tried
url:cfcname.cfc?method=editData&gridaction={cfgridaction}&gridrow={cfgridrow}&gridchanged={cfgridchanged}&returnFormat=json
It still wouldn't work..
Comment 35 written by sneha on 13 September 2008, at 7:23 PM
I used firebug & it showed some error msg while i tried to edit the grid. Here it is:
_251[i] is undefined
if(!_251[i].length){.....
in cfajax.js (line 147)
Not sure what it means.
Comment 36 written by Raymond Camden on 14 September 2008, at 9:30 AM
Comment 37 written by Paul on 24 November 2008, at 4:17 PM
I have a cfgrid that displays in a cfwindow. Looks perfect in FireFox, but when it loads in IE the headers are all messed up. Their text overlaps the columns, they are not aligned properly, etc. Then when you mouse over them they fix themselves. EXT, css and IE related to be sure, but I have no idea how to fix it.
Thanks in advance for any insight.
Comment 38 written by Raymond Camden on 26 November 2008, at 4:41 PM
Comment 39 written by AlexS on 19 December 2008, at 4:00 AM
Comment 40 written by Paul on 19 December 2008, at 11:23 AM
Comment 41 written by Dylan Miyake on 21 January 2009, at 8:50 PM
I have an interesting one here. I'm working on an app that uses CFGrid pretty extensively, with ColdFusion.navigate used to move from page to page.
One thing I noticed that when .navigate is used, the grid objects are not destroyed, so I googled about in the Ext forums and figured out how to destroy them.
But then I noticed that upon multiple page refreshes, IE would start to fail. It appears as if cfgrid.js is appending *two* style sheets to the header with each cfgrid that's created, one with the proper "id-cssrules" (which gets cleaned up by Ext when the grid is destroyed), and one without the suffix (which just sits there in the header), until you hit the magic number of 30 and IE dies.
To work around this issue (temporarily), I've changed line 71 in cfgrid.js to read:
Ext.util.CSS.createStyleSheet(_264.styles, 'foo');
and I'm manually killing the style sheet after destroying the grid:
Ext.util.CSS.removeStyleSheet('foo');
It's pretty easy to see the two stylesheets generated by Ext and cfgrid.js in Firebug, and the IE 30 style sheet limit is documented here:
http://support.microsoft.com/kb/262161
Seems like a pretty hacky workaround to me. Have you (or any other readers of this blog) run into this?
Regards,
Dylan
Comment 42 written by Raymond Camden on 21 January 2009, at 8:55 PM
http://www.adobe.com/go/wish
Comment 43 written by Dylan Miyake on 23 January 2009, at 5:14 PM
http://www.actionscript.org/forums/showthread.php3...
If anyone else is using Flash and the CF Ajax functionality, seeing IE get more and more bloated, check to see if the Skype browser add-ins are the culprit. An application that routinely ate 1GB+ of memory is now down to 80MB or so (still too much, but much more manageable).
Comment 44 written by Chris Ulrich on 9 February 2009, at 8:38 AM
I tried your fix but it didn't work for me. In all fairness, I'm not sure if I'm properly destroying the grids.
I've got a CFLAYOUT structure with menu on the left and "content" on the right. For me, if I click one link on the left that loads a CFGRID on the right, and repeat 13 times, I'm dead. I've added:
javascript:Ext.util.CSS.removeStyleSheet('foo');
to the front of each menu link, such as:
<A href="javascript:Ext.util.CSS.removeStyleSheet('foo');ColdFusion.navigate('rightside.cfm?id=support.faq.edit','supportright');">Maintain FAQ's</A>
This had no effect (and I did change the cfgrid.css in inetpub\wwwroot\cfide\scripts\ajax\package)
Is there a better way to destroy the grid that would make this work?
Thanks
Comment 45 written by Chris Ulrich on 9 February 2009, at 8:50 AM
HOWEVER, if I go click happy, it leapfrogs 2MB per hit, apparently not having enough time to clear (whatever) from memory before the next instance loads...
C'mon IE / Adobe ... play nice! While I love CF, Adobe really should be testing & fixing deeper. If people can come up with work-arounds, they should fix the code.
Comment 46 written by Dylan Miyake on 12 February 2009, at 6:13 PM
Did you also change the cfgrid.js? That's where you assign the name to the stylesheet, so you can destroy it later. I also have a series of hacky workarounds for destroying grids if you're interested.
Dylan
Comment 47 written by Bob Chesley on 28 July 2009, at 12:04 PM
Comment 48 written by futr_vision on 10 August 2009, at 6:14 PM
Comment 49 written by Jared Shields on 11 August 2009, at 6:04 PM
Everytime a new CFGRID is rendered to the DOM, a new style tag (actually I think 2) is added to the DOM (instead of just reusing or adding styles to an already present stylesheet).
IE supports up to 32 (correct me if I'm wrong) stylesheets. We've been experiencing the same issue with my primary application and plan to backout from using any of CF's integrated AJAX controls and just roll with EXTJS directly.... That way it can be controlled more appropriately. Unfortunately I'm not aware of any workaround to this besides modifying the package/cfgrid.js file directly (which I don't recommend).
Comment 50 written by Jared Shields on 11 August 2009, at 6:12 PM
I haven't confirmed whether or not this issue was corrected in CF9 or not, but I doubt it was. Can anyone test and confirm this? (just load a grid into a cfdiv over and over again... and see if it bombs in CF9)
Comment 51 written by Win Barker on 17 August 2009, at 10:55 AM
I've been researching the issues with cfgrid but haven't found an answer to Chris' question from early this year, namely - how do you fire removeStyleSheet() and how (and where) are grids destroyed?
Thanks!
Comment 52 written by frijoles junior on 18 August 2009, at 5:39 PM
Can anyone give me a reason why one form of the grid would go send an incorrect primary key value to the query while the other types do not?
Comment 53 written by Jared Shields on 21 August 2009, at 8:06 AM
I came up with a workaround to the CFGRID/IE/CSS issue with respect to dynamic loading.
I've published the workaround here: http://blog.jaredshields.com/index.php/2009/08/int...
Comment 54 written by Rama on 23 November 2009, at 2:06 PM
I have this weird issue with cfgrid,where i'm breaking my head on that for the past 2 days. I want the cfgrid go to page 2 or 3 on page load and depending on the url parameter "&page =2" . I did an ajax call to the cfc function and got the results for the page 2, but the grid is not taking the data that is returned and it is loading to page 1 by default. My question how can i bind the data that was returned back from ajax to cfgrid? Is there a way. Please help me......
Comment 55 written by Raymond Camden on 23 November 2009, at 4:56 PM
[Add Comment] [Subscribe to Comments]