HypeTimelineAction, HypeSwipe

HypeTimelineAction, HypeSwipe

… are those events muted by the runtime¿

Please elaborate? Meaning not forwarded to an event handler?

Yes :grinning: inactive

I am probably misunderstanding?


events

50

1 Like

HypeLayoutRequest, HypeSceneUnload, HypeSceneLoad, HypeSymbolUnload, HypeSymbolLoad, HypeResourceLoad, HypeDocumentLoad, HypeTriggerCustomBehavior, HypeTimelineComplete and the new HypeScenPrepareForDisplay

These are the events the runtime channels through the notification system. Meaning you can observer them. Other events can show up in the even handler (passed into Hype Functions under event)

Hope this helps.

Having mentioned events forwarded to the notification would probably be good. We could do a workaround…

well, yes i can add a custom callback to the runtime, but why are HypeTimelineAction and HypeSwipe not forwarded¿ any special reason?

@MarkHunte yeah i meant broadcasted by the runtime … :slight_smile:

1 Like

addition: wouldn’t it make sense to pass the parent instance (scene or symbol) along with the timelinename¿

switched it to a feature request :slight_smile:

That would be nice.

The element I comes back as the instance.element() for the time line action in a symbol instance!

1 Like

ah … yes indeed :slight_smile:

This is the functionality in Hype. If you register this as a Hype extension you can forward the event.

/**
* hypeDocument.notifyEvent
* @param {object} containing at least type as name of event
* @param {HTMLDivElement} element
*/
hypeDocument.notifyEvent = function(event, element) {
    var eventListeners = window['HYPE_eventListeners'];
    if (eventListeners == null) {
        return;
    }
    var result;
    for (var i = 0; i < eventListeners.length; i++) {
        if (eventListeners[i]['type'] == event['type'] && eventListeners[i]['callback'] != null) {
            result = eventListeners[i]['callback'](this, element, event);
            if (result === false) {
                return false;
            }
        }
    }
    return result;
};

Updated the reference to the hypeDocument (API) to work in the extension version (this)

so i’ll set up my custom event:
window.HYPE_eventListeners.push({"type":"myFunnyEventName", "callback":thisIsMyCallback});

and wouldn’t this require to call the function myself whenever i need it¿

hypeDocument.notifyEvent({type : "myFunnyEventName"}, someElement)

??? :slight_smile:

1 Like

Yes, this is only interesting if you want to establish Hype type callbacks for what ever reason or when your are creating an extension or want to forward the event.

1 Like

thx for sharing Max :slight_smile:

Your welcome and here is a demo file with many of the built in events you can forward. You can also like mentioned in your example code just invent new events.

This example demonstrates following events:
HypeSwipeLeftAction, HypeSwipeRightAction, HypeSwipeUpAction, HypeSwipeDownAction, HypeTimelineAction, mousemove, keypress, keydown, keyup

Download:
HypeNotifyEventExample.hype.zip

Hope this helps.

2 Likes

There’s no good reason :slight_smile:. I’ve added it to our tracker that all events should go through the notification system.

4 Likes

That is really swell to hear. I think the events your referring to as “all” are the ones in the title. If your planning on forwarding mouse events they fire potentially often and add the notify loops on each call. Keystrokes would be awesome too and overhead should be minimal as the are pretty singular. On the other hand compute power is abundant and even mouse event probably won’t make that much of a difference.

Really great!

1 Like