Hi! thanks for your fast reply however, I've been reading about custom behaviors and I think that through this via is not possible to achieve the functionality that I'm trying to get.
if I have a single function that can redirect tasks based on the value of one of its input parameters, then I could call this function whenever I need to handle an action and avoid having to build multiple functions to handle multiple actions.
you'd need to restructure your code.
something like:
- start a custombehavior that holds the necessary information (cb do not have to preexist, you can built them on the fly ...)
- you can 'catch' this custombehavior with the HypeEvent ' HypeTriggerCustomBehavior'
- then process and redirect ...
this'll require some learning curve, but will offer a lot possibilities regarding Hype-scripting.
Best resource: https://github.com/worldoptimizer/HypeCookBook/wiki, Hype Command Pipeline, https://github.com/worldoptimizer/HypePowerPack
/// simple example special case symbols
cb_messaging.hype.zip (13.6 KB)
///just another example usage cb
swipeElementToMakeLogicalDecision.hype.zip (15.8 KB)
If I am honest I am a little confused as to what the need here is for Custom Behaviours.
I am misunderstanding something ?
In both examples the real meat is in the Additional HTML attributes.
for instance the first example does not need to go near CBs and can just be constructed in the Hype function.
let timelineName = element.dataset.cardinstance
let symbolInstance = hypeDocument.getSymbolInstanceById(element.id);
if(symbolInstance.isPlayingTimelineNamed(timelineName)) return;
let newDirection = (symbolInstance.currentTimeInTimelineNamed(timelineName) == 0) ? hypeDocument.kDirectionForward : hypeDocument.kDirectionReverse;
symbolInstance.continueTimelineNamed(timelineName, newDirection)
And the second just uses Additional HTML attributes.
Not picking, just a bit confused 
1 Like
it's not about necessarity, but usage of cb ... 
1 Like
The use of Custom Behaviors is an option, but is not the perfect way to achieve the main purpose. I give you an image of a theorical Hype, showing the functionality that I'd like to have.
2 Likes
your topic was clear ...
the linked PowerPack-exportscript above should enable sthg. simular, if i remember it right ...
///
simular: Pass value to JS function directly in the Timeline Action dialog
1 Like
Wooooo!
That's it!!!!
Thanks a lot!
I did not know the possibility to make greater Hype importing scripts! Really, really great!
I've dragged the @MaxZieb 's HypePowerPack.hype-export.py file to de right folder and I can see the file in the Scripts inspector in Hype even I did in console the cmmd routine (but I do not receive any message after apply it).
I've prepared a test and when I run it, I've got this message in the console:
Error in HypePowerPack.runFunctionBySelector: ReferenceError: HypePowerPack is not defined
Any ideas please? I'm very close to see the heaven!
My guess: You have to select to use the export script from the preview dropdown (where you can also select the default browser).
Hi, thanks for your quick reply!
I think that I did what you say, in fact these are the two things that I've done:
But I'm still having the same error in console...
This is the file...
Untitled.hype.zip (12.4 KB)
when I saw your answer I thought: "Ohhh I'm close, it seems that this is the key!!...but it does not work...it is very weird isn't it?
I was able to verify that, when I use the option: Run javascript expression, it works perfectly so I guess that I'm not doing correctly when I use the option: run function by Selector, but I don't know what it is...
First a selector is the following…
https://www.w3schools.com/cssref/css_selectors.asp
So, using Rec won't work because there are no nodes called Rec. You would want to select .Rec for nodes with a CSS class Rec. The function then calls the function play based on the settings in your screenshots. Hence, passing the matching element to the function by setting the element to the found one (see signature of the Hype function).
PS: I saw you set the ID to Rec, but that would require a selector #Rec ... but that is not what the function is for. You can do that with regular Hype. Just choose Run JavaScript on click in that case and the element is directly set. The function you're experimenting with makes sense when selecting other elements or multiple elements. If my memory serves me right you can find the usage of this in my example/test file on the download page for Hype Power Pack.
As the thread is about creating your own custom functions you should be focussing on understanding the code and export scripts in general. Hype Power Pack is mainly just a useful example and starting point for that particular endeavor. Furthermore, Hype Bundles will drop soon as Hype build 738 is out and was needed for using document arguments across bundles.
2 Likes
Ok! Finally, all functions are working thanks your advice, thanks a lot again!
1 Like
Yes, it would be nice, but you would need to set the custom parameters as part of the call in the GUI interface, which might be a little cumbersome to pull off.
Sometimes you can achieve the same thing by just looking at the ID of the object which made the request, and then do something custom based on that... or look at the current scene name, and so something based on that, or the current place in the timeline, and then do something based on that. Or a combination of several factors to figure out exactly what you want the function to do.
In most cases this is a work around, but in some cases it is actually cleaner than having to set a specific parameter. I also tend to overuse global variables to track a few items, and often refer to the state of those to determine what the function does.
I like behaviors... but I have found them to sometimes to be unreliable... probably because I did something wrong... but it seems to be easy to do something wrong.
2 Likes
I'm still fairly new to Hype, but I'm a little perplexed as to why it should be so complicated to define a function in a linked JS file and then call it and pass parameters.
Perhaps I've said this before??
I do agree, but I think there is more to it, and it comes down to the fact that Hype doesn't use an open function signature approach for internal functions. Meaning it reserves the signature for it's predefined local variables:
hypeDocument, element, event
Hence, you can't just call any function directly from the action stacks. That option should be in there and as long as it isn't you can thankfully define and use a export script to add the functionality (Run Expression) or an extension like Hype Command Pipeline to map custom behavior calls to functions. The later calling functions you defined on the hypeDocument object and hence giving you the calling scope for free.
Scope as in "execution scope" … hence, the sustained "knowledge" about Hype widget/animation the function was called in. Meaning you can reference local stuff without loosing context when calling a function in Window scope. If you look at this more closely and how people have suggested solutions over the years in the forums, you can see that many approaches disregard scope, telling you to save some variable in window and later retrieve it somewhere else from there. Another classic is people trying to call a Hype function from the window context with the full document name path hard-coded.
These global window solutions might work in plenty of scenarios, but you do run into trouble the moment you use a Hype widget/animation more than once on a page or need to scale a solution.
That said, there are multiple ways to call functions that retain a scope if you need it. Let's look at some of them:
- Pass in the reference (current Hype function model)
- Apply the execution scope (not recommended as it overwrites the
thiskeyword and can get confusing, Prototype vs. jQuery discussion back in the day) - call the function as a member of the API (like
hypeDocument.myFunction, this is how I mostly do it*.
And then there is of course plain global execution that can work as long as you don't need context. Meaning the ability to call any function you might have defined in window. This can be done easily from within a Hype function, but some want this to be done from within the action stacks. I understand why Hype hasn't got it built in as it requires functions to be preloaded or pre-defined in the first place. Meaning when you call window.XYZ (for example), the function would have to be coming from somewhere for you to see results in Previews/Exports (like a script include, or you would need to predefine it in head HTML). This means leaving the confines of Hypes integrated world, and when doing so, you should have some prior knowledge to begin with. Also, the amount of support that comes from people getting into programming and loosing context because they don't understand the concept behind scope would also be pretty big in my opinion. Even now people struggle to call a Hype function from window scope after they "lost" scope or didn't plan for it to begin with.
After all that, I do agree that for "professionals" it should be an option and having a "plugin" (Hype 5 maybe) or now an export script (like Hype Power Pack or the upcoming Hype Bundles being modular) is a decent fix and in my opinion not too much to ask from a "professional" to install.
Tumult Hype is moving very slow in its updates cycles, but many things are well-structured if you look closely … although there are plenty of pain points and frustration in the User Interface and also many powerful concepts and possibilities that are just not exposed to users at first glance (specially "no code" people). That said, the market is moving fast and has alternatives, but Hype's slow evolution might also have its benefits like being a pretty stable environment that rewards continued exploration, custom solutions with reusability over time.
* In the beginning Tumult didn't like it as it means giving up some control over the API and classical programmers don't like that, but JavaScript is built on this open structure (for better or worse)
the simplest setup i'd think of bypassing an HypeEventSetup may be
external:
function doThings(hypeDocument, element, event, str){ console.log(hypeDocument); console.log(element); console.log(event); console.log(str); console.log(hypeDocument.durationForTimelineNamed(str)) console.log(hypeDocument.currentTimeInTimelineNamed(str)) hypeDocument.startTimelineNamed(str, hypeDocument.kDirectionForward) }
call from hypefunction:
function someHypeFunction(hypeDocument, element, event,){
doThings(hypeDocument, element, event, 'xxx');
}
1 Like
That still requires on Hype Function for every parameter variation, and it still pollutes the signature of the function you want to call. Meaning your just forwarding the "problem". Hence, you could just do the calls directly in the Hype function to begin with.
But the idea is good, and I often use the approach by getting my parameter from a dataset value in the context of click actions. This makes the Hype Function reusable.
function yourFunctionNameHere(hypeDocument, element, event){
var myParam = element.getAttribute('data-my-param') || 'Fallback';
alert(myParam);
// call any function like window.XYZ(myParam);
// if you want/need context add it to the call like Hans
// window.XYZ(myParam, hypeDocument)
// or if that is not possible (re)create a wrapper function
// on the fly before calling it
// window.XYZ = function(p){alert(p, hyDocument);}
}
Download:
ClickButtonParameter.hype.zip (137,7 KB)
1 Like