David: Yep, I’m half familiar with how the behaviours work
Andrew: Think about behavior as an windowless control attached to the existing dom element.
Say here (image on the right) behavior draws clock hands only and CSS defines clock face and glass.
David: aah, ok – so you define the behaviour classes as a subclass of the behaviour class, and then include functions with whatever events are needed
David: The clock example is a good one.
Andrew: In CSS you define for your element: #myelement { behavior:mybehavior } and while parsing HTML with something like < div id="myelement" > I will call your callback with the name “myelement”
David: like “clock {behavior:clock;” etc in the clock example. I’m getting it now 🙂
Andrew: behaviors are event handlers changing attributes and states of DOM elements. And CSS is used as a “styler” of these states. This is the main idea of “interactive HTML” . Clock example goes even further – it defines rendering behavior.
Andrew: More on this: behaviors allows you to define interactive, well, behavior of HTML elements.
David: Basically, if it’s not able to be done in regular HTML, you can add it in as a behaviour.
Andrew: Exactly.
Andrew: Behavior as a component can be reused in many places – they are solid building blocks of UI. Styling of various states is more dynamic – each project/application/brand requires its own appearance. Think about CSS and its ability to style states as a “skin” for your application. Style system could be made customizeable by users if needed.
David: With windowless rendering such as PrintEx and HTMLite, when HTMLayout calls a callback function, how does the host app know which html canvas it’s coming from?
Andrew: HTMPrintGet/SetTag
Andrew: Put in the tag reference to the canvas (this)
David: Excellent. Much like the GWL_USERDATA that you can set with regular windows
Andrew: Correct
David: cool
Andrew: There is a C++ PrintEx class in the header that does exactly this. And it delegates callback calls to virtual methods.