Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Event Binding in VFP 8 : Page 4

For most applications, events are what drive the development effort, but event handling doesn't offer developers much flexibility. But in VFP 8, event handling is changing for the better.


advertisement

Events vs. Methods
One of the little known facts is that Visual FoxPro internally handles different events in different ways. This has to do with Visual FoxPro's history. Some events, such as When() and Valid() go way back to pre-Visual versions, while others were introduced with Visual FoxPro 3.0. The difference is that some events are true events, while others are just simple methods that are being called when certain things happen, which makes them look like true events for most purposes.

For manual event binding, however, the difference is significant. It would be very difficult for most developers to first figure out whether an event is a true event or just an automatically fired method. For this reason, the Visual FoxPro team built the BindEvent() function so that it also allows you to bind any type of handler method to any other method. This way, we can bind to all sources of events equally.

This has the convenient side-effect that we can bind handler methods to all types of methods, no matter whether they are internal methods or custom methods defined by the developer. For instance, we could add a method called "SomeMethod" to the form. We can then add another method called "SomeOtherMethod" to the same form and bind that method to the first method:

   FUNCTION Init
      BindEvent(THIS,"SomeMethod",;
         THIS,"SomeOtherMethod")
   ENDFUNC
Now, whenever SomeMethod() gets called, SomeOtherMethod() fires as well.

Sometimes, this behavior may not be desired. For instance, one might want to bind to the Click() event, but not to the Click() method. This can be done using an optional flag:

   BindEvent(THIS.cmdOne,"Click",THIS,"Handler",2)
Every application that fires events can be extended using manual event binding.
The "2" in the fifth parameter indicates that we do not want to bind to the Click() method, but only to the event. If someone clicks on the button, the handler method will fire. However, the following code would not invoke the handler method:



   THIS.cmdOne.Click()
Of course, this only works because Click() is a true event (unlike Valid(), for instance).

BindEvent() is a very powerful new feature. It is probably not a feature that every developer has been waiting for, but those of you who have a need for this feature need it badly.



Markus Egger is president of EPS Software Corporation, located in Houston, Texas. He is also the founder of EPS Software Austria, located in Salzburg. He concentrates on consulting in COM-based, object-oriented development and Internet applications. He is an international author and speaker, and is co-publisher of Component Developer Magazine. He is also the author of "Advanced Object-Oriented Programming with Visual FoxPro," from Hentzenwerke Publishing. For the past several years, Markus has received the Microsoft MVP award. Several applications he has worked on (mostly as project manager) have received Microsoft Excellence Award nominations. He is the author of several tools, such as GenRepoX (public domain), the Fox Extension Classes, and Visual WebBuilder. A full bio can be found on the web at: www.eps-software.com/MarkusEgger. You can reach Markus at megger@eps-software.com.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date