>Why not just call HeaderClicked from the click directly then? What advantage do you get by using RaiseEvent/BindEvent?
Nothing huge, but because there are inconsistencies with native events I prefer to ignore them all together, and I don't do alot of event binding in the UI to begin with.
I remember using the VFP8 beta and binding to the Click() event of a regular command button. The code would fire when the button was literally clicked on but not when it was tabbed to and the space bar was hit. The button would look like it was being clicked but the delegate woudln't fire. I don't know if thats been fixed or not, but I wouldn't be surprised if there are other issues with accessibility or automation code where delegates are being fired.
Ever tried to BindEvent() to AddObject()? I haven't, but someone on the WW board did and didn't work for them. You're better off raising a custom event and binding to that:
http://fox.wikis.com/wc.dll?Wiki~BindEvent~VFPI'd rather just use native UI events the way I've been using since VFP3 and use RaiseEvent()/BindEvent() for communication between tiers and busines objects.
>This still leaves you with the issue of getting your header class into the grid. Member classes don't work for grid headers. (At least not as far as I can tell.) Do you add the headers at runtime? You lose a lot of advantages of a WYSIWYG designer if you do. What if you ever forget that this will happen, and change header properties in the designer?
Runtime, its never been a problem before.
