Then I'd use a custom component instead of <mx:DateField> itself, rather than trying to shoehorn stuff into the existing DateField impl. It just seems like you're setting yourself up for way more work than you need to is all.
The order I'd try is: 1. Custom component instead of DateField, that contains in a hbhox both a DateField and a (today) button. It doesn't *need* to be in the popup does it? 2. Subclass DateField, intercept popup creation, attempt to add your button to popup after its CreationComplete 3. Subclass DateChooser and override CreateChildren. Probably not too hard, but I haven't poked into the source so don't quote me, and I've no idea what effect it'll have on the skin. -Josh On Fri, Jul 18, 2008 at 4:36 AM, duncan_coutts <[EMAIL PROTECTED]> wrote: > Hi, thanks for the reply. The reason for not simply using the VBox > solution is because the extended DateChooser must act as the date > chooser which pops up when the user clicks the icon next to the text > input field of a date field. The date field has a dropDownFactory > property which can point to a factory which creates instances of the > derived version of the DateChooser. However, the dropDownFactory must > return a DateChooser (or Derived DateChooser). Therefore, I can see > that I will need to create the derived dateChooser as an action script > component. > > > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
