Swipes that move between cards generate navigate[] events, just like pressing the left or right arrow keys. You can override the default behavior by defining an empty handler for the navigate[] event on the card- or deck-level script, like so:
on navigate do end
Does that solve your problem?
While Dialogizer is active, the view[] events requested by flagging a widget as .animated won't be produced naturally by Decker itself; all system events are "blocked" until the synchronous call to dd.say[] completes. Dialogizer sends a "synthetic" animate[] event to the current card every frame, and then you can in turn use that event to explicitly send a view[] event to other widgets that need to animate (or call the view[] function on the card, etc).
Perhaps your card script could have something like:
on animate do if alarm.animated alarm.event["view"] end end
Or maybe you could do something a little more generic, querying the card to find any animated widgets and pump view[] events to them:
on animate do (extract value where value..animated from card.widgets)..event["view"] end
This animate[] event is also how Puppeteer manages the animation for puppets. If you're using these libraries together, make sure your own animate[] event handler calls
pt.animate[deck]
at some point. You can also take a look at the card script for this part of the Dialogizer tutorial: http://beyondloom.com/decker/dialog.html#eventpumping
Does that help?
Thank you!
alarm.event["view"]
does exactly what I need. The event pumping is something I missed when I was looking through tutorials. Thanks again.
It would be reasonably straightforward to sort the sound, prototype, and font lists alphabetically when they are displayed.
Is there a specific workflow that you're having trouble with?
For example, in my current project, I’m using a lot of sounds and prototypes. For the sounds especially, it is hard to identify what I’ve imported/used/can get rid of simply because I have to scroll up and down trying to find that particular filename.
This is mostly because I’m a fanatic and will re-edit sounds if they’re too loud or the loop isn’t quite right.. so even though I organize all my filenames before import, they still end up out of order if I delete/re-import a re-edited sound because they’re plopped back down to the bottom of the list. Does this make sense?
In my game, I moved some of the common logic to the deck-level script. However, when I make a call to one of the function from the deck (e.g., deck:set_progress[me 2]), it breaks the Dialogizer altogether. The `dd.open[deck], dd.say[...], etc, dd.close[]` just stops working. So weird.
I created a very simple deck where I reproduce the behavior: 
I would appreciate any advice on this.
The phrase
deck:some_function[]
calls a function named "some_function" with no arguments and then assigns the result of calling that function to a variable named "deck". If the result of that function isn't the deck (it appears to be the number "1" in your example), you will then be calling the dialogizer functions with an invalid "deck" argument, which prevents them from working correctly.
If you have defined a function in a deck-level script:
on some_function argument do argument+2 end
You can invoke it from any card- or widget- level script by calling it like any other function:
some_function[3]
Widget scripts exist in a scope nested inside card scripts, which in turn exist in a scope nested inside the deck level script which in turn is nested inside a special magical scope with the definitions of all the default event handlers. Every variable or function definition in an outer scope is visible to the scopes nested within it, unless one of those scopes "shadows" it with a local definition with the same name.
Widgets, Cards, and the Deck all expose a ".event" attribute which is a function you can call to send a synthetic event to that deck-part. You can thus also invoke that deck-level function from elsewhere like so:
deck.event["some_function" 3]
This latter method works even if the target is not in a scope surrounding the caller, and it sets up automatic variable bindings ("me", the widgets on a card by name, etc) from the perspective of the target. This is most useful when you want to communicate across cards or simulate user interaction, like sending a button widget a "click" event which appears from that button's perspective like a user-generated click.
Does that help clarify?
Unfortunately, Decker does not currently support Cyrillic.
Decker uses an internal byte encoding called DeckRoman, which supports a variety of diacritics and special letters for Latin-based alphabets, and provides a range of fonts with those characters.
It is possible to represent other alphabets using a custom font, but this does not automatically make Decker recognize natural text input in those alphabets.
For a more determined tinkerer, it is within the realm of possibility to fork Decker and modify the lookup tables it uses for converting between UTF-8 and DeckRoman, but this would require some programming experience.
Your "srch" and "show" variables contain strings. In the context of a query subexpression they will be interpreted as string values, not the contents of a column by name. You can, however, use the implicit "column" dictionary to perform this indirection, something like
result:select column[show] where column[srch] like term from internal_copy.value
(the "column" dictionary is also how you can reference columns whose names are not valid lil identifiers.)
You might want to take a look at the examples for the "_hideby" column in grids; it's designed to assist in searching and filtering grid contents without requiring an auxiliary source of truth.
