Sietse,

I guess my wording was poor. I was trying to point out that calling the

click method is not the same as clicking on the button.

And I forgot about the fact that the code in the method still fires,

even if I bind the event to a different method. Thanks for making that

clear.

Let me try explaining the difference again and let me know if this is

better.

I can bind an event to a method. The example is that if I bind the

doubleClick event for all the columns, headers, and text1 items in a

grid to the grids doubleClick method, then I don't need to have any code

in doubleClick for those items.

However, if I have some code that is supposed to call the doubleClick

method of a textbox in that grid, I couldn't just call

grid1.column1.text1.doubleClick() because there is no code there.

I could use RaiseEvent to raise the doubleclick event of that textbox

which would then result in the doubleclick code in the grid firing (just

as it would if the user doubleclicked on it.)

How does this sound?

Fletcher

-----Original Message-----

From: profox-bounces@leafe.com [mailto:profox-bounces@leafe.com] On

Behalf Of Sietse Wijnker

Sent: Monday, October 24, 2005 4:21 PM

To: profox@leafe.com

Subject: RE: BindEvent and RaiseEvent

> -----Original Message-----

> From: profoxtech-bounces@leafe.com

> [mailto:profoxtech-bounces@leafe.com] On Behalf Of Johnson,

> Fletcher S (N-Superior Technical Resources Inc.)

> Sent: dinsdag 25 oktober 2005 0:34

> To: profoxtech@leafe.com

> Subject: RE: BindEvent and RaiseEvent

>

> Grigore,

>

> Warning, this concept can be rather mind bending. But if you

> choose to continue, you do so at your own risk.....

>

> Consider this. If you click on a button on a form, is that

> the same as calling the forms click method?

>

> If you turn on event tracking, you will see that not only

> does the click event fire, but also the mouse enter, mouse

> over, mouse move, mouse down, and mouse up (I am going from

> memory, forgive me if I made a

> mistake) events fire.

Actually, The click event you can edit in the code editor is the Click

method. The Click event is handled internally in VFP and isn't open for

editing. When you bind another method to the click event you can set the

bindlevel using the earlier mentioned parameter. This way you can set it

at event-level or at the codebehind level (click-method). The raiseevent

actually triggers the internal click-event. The commandbtn.Click() call

only fires the codebehind method. Actually you can

>

> Bindevents is used to change the method associated with an

> event. By default, the click method of a button will call

> that buttons "Click"

> method. You can use BindEvents to change it so some other

> code is executed. This can be especially useful when it is

> hard to set default methods (say for a grids column header,

> textbox, column, etc) in parent classes.

You don't change the code that was originally executed. The original

click-method is still fired. The bound method is fired prior or

afterwards (depening on, again, parameters in the bindevent-call). So it

doesn't override code already in the cmdbutton.click()!! The

Grid-header, textbox and other classes used in the grid are indeed

especially a good use of the bindevent. In the Init of the grid you can

bind all the controls dblClick events to the grid's custom

ControlDblClick() method and you'll never have to write code in any of

the controls used in the grid to handle doubleclicking. Good example!

Regards,

Sietse Wijnker

[excessive quoting removed by server]