| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I currently was using multiple inheritance to define the message classes
that a class supports, but this caused problems when, for example, a
class tested to see if an object supported CMouseMsg. The class in
question supported several mouse messages, but a standard dynamic_cast
returned nullptr for the class, since it didn't directly support it
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Turns out that some of the messages have properties that the objects
that handle them can set. For example, the CMouseDragStartMsg has a
_dragItem property that an item that allows dragging will explicitly
set, allowing the input handler to keep track of what was dragged.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is necessary for at least message sending, and probably other
areas, that needs to be able to pass class filtering for message
targets. And I could figure out a clean way to use the built-in RTTI
|
|
|
|
|
|
|
