datefield overlaps

[ToBeNamedLater]

If you have a page with more than one <cfinput type="datefield"> and they're close to each other, they'll overlap when you open the calendar. This seems to happen only in IE. It seems to be related to z-index. If no z-index is specified, zero is assumed, and IE puts later ones (lower on the page) on top of earlier ones (farther up the page).

So here's a custom tag called CalendarZIndexIEHack that will work around the problem. This is probably also doable using the underlying ExtJS library, but I don't have time for that when this works just as well.

Take this code and store it in a file named calendarzindexiehack.cfm and put it where your custom tags are.

Usage:

<cf_calendarzindexiehack><cfinput type="datefield" name="datefieldname" [etc] /></cf_calendarzindexiehack>

If this is fixed in a later version of CF or Ext, just remove all the code from the tag. That will eliminate having to edit all of your code when (or if) the fix is made. This will handle up to 500 date fields on a page. (Edit in the obvious place if you have more. More !?!?!)

[ToBeNamedLater]

I should say that I've only tested this in IE/Windows and FF/Windows. It has no effect on FF. (But you could branch around code if the user-agent isn't IE if it bugs you).

I have not tested in other browsers or on other platforms.

Reports of your experience are welcome.

[CutterBl]

This is actually a fault of IE itself, and is a known issue for a very long time. There are other ways around it, but using the built in datefield isn't one of them. I believe there is a JQuery plugin, with a datefield component, that can bypass this issue. Not positive, but I seem to remember it if you check the plugins page of the JQuery site (jquery.com)

[ToBeNamedLater]

I know it's an IE problem, but the odds of getting Microsoft to fix their bugs is even longer than getting Adobe to fix theirs which itself is as close to zero as to be immeasurable.

I'm not inclined to include yet another package and all its baggage (whatever that might or might not be).

This "RAD" development is becoming considerably less R.