![]() This action will show a sheet window where we will be able to choose any of the already available Class Interfaces in the Xojo Framework for our subclass. Select the CustomCanvas item and push the Interfaces button on the Inspector panel. This action will create a new Canvas based subclass with the name “CustomCanvas”. Then, drag the Canvas icon from the Library panel and drop it into the Project Browser (the leftmost column of the IDE). Go ahead and create a new Desktop Project using the Xojo IDE. So let’s use these Class Interfaces to see how they apply on our example app. ActionSource and ActionNotificationReceiver at Work the event organizer will notify every registered person about the availability of the tickets). In fact, the ActionSource and ActionNotificationReceiver work together, because an ActionSource instance (PushButton, BevelButton or Timer) will call the PerformAction method of every ActionNotificationReceiver object registered with it (i.e. Best of all, you already can do this kind of things via the ActionSource and ActionNotificationReceiver Class Interfaces. Sounds weird? Ok, it’s like a group of people interested in one event saying the organizer: “hey, notify me once the tickets are available for purchase”. This one consists on the ability for any class instance to register itself into other instance, in order to receive a message every time there is an action in the object we have registered on. That will work, but undoubtedly is not the most elegant, flexible and decoupled of the possible solutions.Ī better way of approaching this problem is using the Observer Design Pattern. For instance, we can put the code in charge of iterating every window control into the “Action” event of the PushButton control, changing the color only if the iterated item is an instance of our Canvas based subclass (let’s call this class the ColorPatch class). Of course, we can approach this from several angles. Let’s suppose we want to create an app where several Canvas controls have to randomly change their color every time we push a button. In Part 2, we will see how to implement the Observer Design Pattern from scratch, using our own Classes and Interfaces, so it will be easier to understand the mechanisms behind this Pattern and how to use it. This one will focus on how easy is to implement using the interfaces already available in Xojo for UI controls like the PushButton, the BevelButton, and also for the Timer class. In fact, this is the first of a two part series regarding the Observer Design Pattern. This one solves the kind of question “How can the ‘x’ controls be automatically notified every time there are changes on ‘y’?” Sound interesting? Let’s see how! Now, it is time to look at another useful Design Pattern you can use in your apps: the Observer Design Pattern. In a previous post we saw how to implement the Singleton Design Pattern in our Xojo apps.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |