developers events

Developers - Events

History

When CardMaker was originally created it was with a limited vision for maintenance and expandability, specifically in the way the Forms within the application interact with one another. The various Forms were authored to directly access one another through via exposed Instance properties. This resulted in a lot of difficulty as the application expanded and offered more unique functionality requiring things like emulating a form action (like programmatically selecting a layout).

Goals

• Centralize event handling - funnel cross form interactions through central managers so any Event listener can be alerted and act accordingly
• Remove all cross form direct access -- No more random MDI(formname).Instance.SomeMethod() calls!
• Remove all MDI(formname).Instance properties
• Put the Forms at the top of the event food chain -- This is just a choice. The MDIProject Form should be in charge of selecting a Layout. That's where users click and select layouts. Any programmatic call to do so should go through a request Event.

Design

Two important points:

• This is not perfect
• This is a work in progress based on the needs of the application

Events

Updated / Changed Events

These indicate that something has changed and is ready for evaluation.

Request Events

These indicate a desire to change something to the specified value (often specified in the Event args).

Event Managers

With the new design there are multiple event managers, each with a general purpose.

• ElementManager
• IssueManager
• LayoutManager
• LayoutTemplateManager
• ProjectManager

Each manager is generally responsible for dealing with the associated events.

Fire X Event Methods

To avoid directly accessing other Forms there are a number of supporting event trigger methods. These are intended to be used when a modification to a data object should be broadcast to all potential listeners.

Event Flow

Events are generally started with user interaction, like selecting a Layout in the Project window. This cascades through a number of events resulting in the layout being loaded and a references being loaded from their sources.

In some cases these top level user interaction Events need to be triggered outside of the normal flow. An example of this would be when a user selects an Element from the Canvas window. Instead of directly accessing and adjusting the Elements in the Layout control a request event is emitted with the name of the Element that should be selected. The layout control handles the Event by performing the same operation as a user interaction would, selecting the desired element in the Listview of Elements. The selection results in the same cascading sequence of Events. This unifies the Event flow for user and non-user adjustments within the application.