Environment and Events
Danger
A complete version was never completed!
CodeCoupler System & Application
CodeCoupler System and Application instances fires events which should used around the topic which
panel is fronted. CodeCoupler use the library jsPanel to create application panel which have an own
event named onfronted
. You can use the jsPanel this event of course, but this would have some
disadvantages:
- The
onfronted
event will be fired too often. Each click inside a panel triggers the events, even if the panel is already fronted. - It is difficult to distinguish between application panels started in a stage and inline applications.
- An event
unfronted
do not exists. - It is difficult to distinguish between applications of the own system and other systems.
Therefore the following events will be triggered:
- A CodeCoupler System instance will trigger an
fronted
event whenever the fronted application of the own system has changed. As event argument you get the application instance. This event will not be triggered for an application that is already fronted. - A CodeCoupler Applcation instance will trigger the events
fronted
andunfronted
if the application will be fronted or another application will be fronted. Both events will not be triggered more as then neccesary. - The current state of the
fronted
member of an inline application matches the state of the parent application in which the inline application is started.fronted
events will only be triggered if the parent application triggers the events.
Event listeners to this events can be added as follows:
In an application:
1 2 3 |
|
In a widget:
1 2 3 |
|
Furthermore you can read from an application instance the current state (if fronted or not) the
member fronted
. This is very important to read initially this state because no event will be
triggered on start:
1 2 3 4 |
|
CodeCoupler Widget
CodeCoupler Widget instances triggers the event visibilitychanged
which have the following
meaning:
The property fullvisible
of a widget can be true
or false
. If true
the widget is in a
fronted application and not in a stack in which the widget is not visible.
The value false
can mean the following: The widget is in an application that is not fronted, or
the widget is in a fronted application but in a stack and the container is at this time not active
and so invisible.
The event visibilitychanged
will be triggered if this value changes. It will not be fired at the
start of the widget.
"Full Visible" means that the widget is really visible now. "Not Full Visible" means that the widget is most likely not complete visible. In the case that another application will be opened in a desktop alike mode the widget gets the state "Not Full Visible" but it will not checked if the fronted application really overlaps the widget.
To demonstrate the event we will write a small widget:
widgets/testing-visibility.js
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Now we modify our first application and replace the widget number 4 which is configured in a stack:
apps/testing-buttons.js
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 |
|
In the console you can now see the changes of the property whenever you bring the widget into front or start another application.
Custom Events in Application and Widgets
Each application and widget have an event dispatcher which can be used for custom events. Bind to
events can be done with on(eventName, eventFunction)
or to execute only once with
one(eventName, eventFunction)
. Events can be triggered with trigger(eventName)
. Specific event
handlers can be removed with off(eventName, eventFunc)
and all handlers belongs to an event with
off(eventName)
. With off()
you can remove all handlers of all events.