My control is being stored in a Windows DLL and therefore it exports *only* functions - I am quite sure you cannot export objects due to the double pointer required by an object->method call. It's possible a newer breed of .NET enabled DLL's offer this functionality but assume I'm exporting functions not objects.
My control is being implemented following a strict MVC design where the controller is the object/component.
The controller is essentially a message pump and a switch handler which invokes appropriate event handlers - which in turn will pull on models and update the view(s).
Code: Select all
class Controller{
static msgPump()
{
switch(evt){
case WM_CLICK: // Handle mouse events
break;
}
}
static onClick()
{
// Pull on model object
// Update view object (which wraps a generic Windows window)
}
// Exported function
static createControl()
{
// 1) Create the view object
// 2) Inform View object how to communicate back to controller
}
}1) msgPump() is the control entry point and acts something of a page controller. It captures all user requests and delegates them to appropriate event/action handlers. This is private to to the component.
2) onClick() is a controller action. It is invoked by the msgPump() whenever someone "Clicks" inside the control. This function is also private to the component.
3) createControl() is a component exposed API function. It's called by client developers.
My question is, when modularizing my code, should I have a seperate class for the API of the component, even though they are part of the controller, as it is a client way of directly invoking an action (createControl, moveControl, etc) as opposed to indirectly via an event handler, such as onMouseMove, onSelectionStart, etc...
Make sense to me to modularize the classes, what you think?
Cheers