Hello, everyone

I think I am missing the phylosophy here. What's the difference between

these two? As far as I can understand, I can raise an event from any method;

in other words, RaiseEvent can cause a custom method to behave like an

event - to get executed when something happens. Well; let's assume in a

button Click() snippet I enter a RaiseEvent() and raise a custom method as

event. The same can be achieved by binding through BindEvent my custom

method and button's Click(). Also, I can simply call my custom method from

button Click().

What's the difference? what can be done thru RaiseEvent and cannot be done

thru BindEvent()? a sample would be greatly appreciated. I don't understand

what I am missing, although I am obviusly missing something.

Thank you.

Grigore Dolghin wrote:

> <snipped>

> What's the difference? what can be done thru RaiseEvent and cannot be

> done thru BindEvent()? a sample would be greatly appreciated. I don't

> understand what I am missing, although I am obviusly missing something.

>

BindEvent supports both Early and Late binding - not too sure about what

RaiseEvent does.

Matthew S. Jarvis

IT Manager

Bike Friday - "Performance that Packs."

www.bikefriday.com

541/687-0487 x140

mattj@bikefriday.com

Maybe I got this wrong. I have played with binevents and windows api but not

raiseevents

If I have it right Bindevents causes a method to action when the event its

bound to occurs where raiseevents causes an event to take place.

Allen

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

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

Behalf Of Matthew Jarvis

Sent: 24 October 2005 21:41

To: profoxtech@leafe.com

Subject: Re: BindEvent and RaiseEvent

Grigore Dolghin wrote:

> <snipped>

> What's the difference? what can be done thru RaiseEvent and cannot be

> done thru BindEvent()? a sample would be greatly appreciated. I don't

> understand what I am missing, although I am obviusly missing something.

>

BindEvent supports both Early and Late binding - not too sure about what

RaiseEvent does.

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.

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.

Bindevents is also limited to native VFP objects/classes

RaiseEvents is used to actually raise the event. If you look at the

online help, you will find the following example:

Activating a form or using Form1.Show triggers the Activate event for

the form. However, calling the Activate event directly using a call such

as Form1.Activate does not trigger the Activate event. The following

example shows how you can use RAISEEVENT( ) to trigger the Activate

event:

RAISEEVENT( Form1, "Activate" )

You might also look at the foxWiki

<http://fox.wikis.com/wc.dll?Wiki~EventBindingSample> for some

additional information on this.

I believe you can also use Raiseevents to raise events in other COM

automation resources - but I can't quite recall for sure.

I haven't done much with this lately, I am sure that Nancy, Ted, Ed, and

a few others will chime in with something more clear.

Take care,

Fletcher

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

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

Behalf Of Grigore Dolghin

Sent: Monday, October 24, 2005 1:26 PM

To: profox@leafe.com

Subject: BindEvent and RaiseEvent

Hello, everyone

I think I am missing the phylosophy here. What's the difference between

these two? As far as I can understand, I can raise an event from any

method;

in other words, RaiseEvent can cause a custom method to behave like an

event - to get executed when something happens. Well; let's assume in a

button Click() snippet I enter a RaiseEvent() and raise a custom method

as

event. The same can be achieved by binding through BindEvent my custom

method and button's Click(). Also, I can simply call my custom method

from

button Click().

What's the difference? what can be done thru RaiseEvent and cannot be

done

thru BindEvent()? a sample would be greatly appreciated. I don't

understand

what I am missing, although I am obviusly missing something.

Thank you.

[excessive quoting removed by server]

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]

Johnson, Fletcher S (N-Superior Technical Resources Inc.) wrote:

>Bindevents is also limited to native VFP objects/classes

>

>

I wanted to point out 2 things.

In VFP 9 you can bind events to Windows Messages

You can use the EventHandler() function to bind COM server events

to interface methods of VFP objects

--

It's all relative

Eugene Vital

EGN-Tech www.egntech.com

Coming in late ... Looks like the original question was answered (and

then some!)

I'd just like to add my impression that Bindevents is a 'megatool'. In

the archives you'll find a discussion where I mentioned now being able

to add a single line of code to INIT for each new grid/class to add

column sorting to every column in the grid in one stroke, uniformly and

with assurance that later changes to the grid will not mess this feature

up in any way.

I think that, like every other tool in our bag, we need to know when to

use it and when not to. One concern I feel is that we also need to pay

special attention to documenting the use bindevents so we don't drive

Joe Maintainer nuts ("where the heck did THAT come from?").

Okay, just thought of this, but maybe similar to using an 'object

factory' to create objects, a 'bindevents factory' can handle

bindevents. The object factory (if I'm using the term correctly)

maintains a cursor of currently active objects. Similarly, the

bindevents factory can maintain a cursor all active bindevents, and that

way Joe can have diagnostics showing all current objects and active

bindevents (viewable in a separate diags screen, of course). Be a good

reminder they are active in the system.

Bill

> Hello, everyone

>

> I think I am missing the phylosophy here. What's the

> difference between

> these two? As far as I can understand, I can raise an event

> from any method;

> in other words, RaiseEvent can cause a custom method to

> behave like an

> event - to get executed when something happens. Well; let's

> assume in a

> button Click() snippet I enter a RaiseEvent() and raise a

> custom method as

> event. The same can be achieved by binding through BindEvent

> my custom

> method and button's Click(). Also, I can simply call my

> custom method from

> button Click().

>

> What's the difference? what can be done thru RaiseEvent and

> cannot be done

> thru BindEvent()? a sample would be greatly appreciated. I

> don't understand

> what I am missing, although I am obviusly missing something.

>

> Thank you.

>

>

>

[excessive quoting removed by server]

Hi Fletcher,

Better but not quite there yet;-)

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

This depends on the binding params. If you set it up to bind it at the

code-behind level (default), then calling just the

grid1.column1.text1.doubleClick() will do the trick triggering the grid's

doubleclick. If you bound it at event-level you indeed have to use the

RaiseEvent() to trigger the grid's dblClick.

Regards,

Sietse

Hey Bill,

> Okay, just thought of this, but maybe similar to using an

> 'object factory' to create objects, a 'bindevents factory'

> can handle bindevents. The object factory (if I'm using the

> term correctly) maintains a cursor of currently active

> objects. Similarly, the bindevents factory can maintain a

> cursor all active bindevents, and that way Joe can have

> diagnostics showing all current objects and active bindevents

> (viewable in a separate diags screen, of course). Be a good

> reminder they are active in the system.

>

You off-course can provide in a tool thet uses the Sys(1270) and the

AEVENTS(laBind, oObject) to provide Joe in a method of 'reading' which

methods are delegated to others.

Sietse

> > Okay, just thought of this, but maybe similar to using an

> > 'object factory' to create objects, a 'bindevents factory'

> > can handle bindevents. The object factory (if I'm using the

> > term correctly) maintains a cursor of currently active

> > objects. Similarly, the bindevents factory can maintain a

> > cursor all active bindevents, and that way Joe can have

> > diagnostics showing all current objects and active bindevents

> > (viewable in a separate diags screen, of course). Be a good

> > reminder they are active in the system.

> >

> You off-course can provide in a tool thet uses the Sys(1270)

> and the AEVENTS(laBind, oObject) to provide Joe in a method

> of 'reading' which methods are delegated to others.

Hi Sietse,

True, but by using a 'control point' other information can be collected

as well, such as who issued the bindevents, when, and perhaps even why.

Bill

> Sietse

>