By default, the Microsoft VM uses JavaBeans introspection to enumerate the methods and properties that are exposed through IDispatch. Unless a Bean provides its own BeanInfo, all public methods are exposed, as well as properties discovered using standard design patterns (such as setText and getText).
In addition to exposing event interfaces, ActiveX controls have the concept of a default, outgoing set of events. A control developer defines this default event set, which is often the only event source connected to by ActiveX containers. To provide the greatest flexibility to Java developers, the ActiveX control framework allows use of design patterns to define this default event interface.
Since the JavaBeans eventing model is sufficient for many eventing needs and maps well to the ActiveX IConnectionPointContainer model, Microsoft recommends that events be exposed using the JavaBeans eventing specification.
When an ActiveX component attempts to connect to the default event interface of an ActiveX control for Java, the Microsoft VM introspects that control and looks for event listener interfaces. Unless a Bean provides its own BeanInfo, all outgoing events are in the default event set. For example, a developer could define the following interfaces in Java to define its outgoing default event set.
interface mouseListener { public void mouseEvent( int ButtonState, int x, int y ); } interface buttonListener { public void clickEvent( Object ButtonSource ); } interface keyListener { public void keyEvent( int shiftState, int key ); }
These interfaces define events that could be sourced from three different JavaBeans event connections in a Java control. The Microsoft VM will combine them into one interface that is exposed through ActiveX. Be aware that the methods in the interface freely define parameters that are not event objects. The JavaBeans specification states that this free-form method specification is fully supported, but not necessary. It can improve performance in passing events in and out of Java.
To attach an event sink to the Java control, the Microsoft VM calls the addListener methods of the outgoing event sources and passes the instance of an object, which implements the appropriate interface.
Properties allow control developers to expose state variables that can be queried, set, and monitored by other controls or control containers. Again, the JavaBeans model provides a one-for-one mapping with ActiveX property concepts and change notifications. The Microsoft VM exposes ActiveX properties based on design patterns and BeanInfo information as detailed in the JavaBeans specification.
To source property change events (equivalent to ActiveX OnChanged events) a developer can simply support the JavaBeans addPropertyChangeListener and removePropertyChangeListener methods, which accept the propertyChangeListener interface as a parameter. Likewise, to source vetoable property change events (equivalent to OnRequestEdit events), a developer just supports addVetoableChangeListener and removeVetoableChangeListener methods, which accept the vetoableChangeListener interface as parameters. The Microsoft VM will automatically connect to these property change event sources and handle them appropriately. To ActiveX clients of the object, these events will map to IPropertySinkNotify and IPropertySinkNotify::OnRequestEdit.