datefield overlaps

If you have a page with more than one %26lt;cfinput
type=''datefield''%26gt; 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:



%26lt;cf_calendarzindexiehack%26gt;%26lt;cfinput type=''datefield''
name=''datefieldname'' [etc] /%26gt;%26lt;/cf_calendarzindexiehack%26gt;



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 !?!?!)





datefield overlaps
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.datefield overlaps
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)
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.