Decker does not have the ability to execute shell commands or otherwise interact with the host system without explicit user permission; "shell[]" and similar functions are part of Lilt, which has a similar but distinct set of APIs from Decker itself.

As it happens, there is a way to print to stdout from Decker in the latest source revisions- the "app.print[]" and "app.show[]" functions. Note that this feature is not part of Decker v1.31, the current release at time of writing.

There is  presently no mechanism for polling from stdin. The closest analogy might be to use the alert[] function:

alert["please input a string:" "string"]

I think I follow you.

Copying rich text from one field to another requires accessing their "value" property. Let's say we have rich text fields name "target", "a", and "b". The "a" field contains a link, and the "b" field does not:

In the button above I have a script like this which randomly picks between the value of "a" and "b":

on click do
  target.value:random[(list a.value),(list b.value)]
end

In this example, the values each need to be wrapped in a sublist with the "list" operator before joining them together with "," to prevent the rich text tables from being fused together into a single table.

The "a" and "b" fields could be hidden from view (Widgets -> Show None), and this approach generalizes to any number of alternative texts.

If you want to programmatically modify existing rich text to insert links it's a bit more complicated. Rich text is represented in Decker as a table, and the rtext interface contains some functions that can make it easier to manipulate such a table. If you wanted to change the styling of a specific range of characters within a field, you could use rtext.span[] to grab the text before and after your region of interest, retaining their existing styling, rtext.string[] to extract a region of interest without its styling, rtext.make[] to create a new styled chunk (including a hyperlink or inline image), and rtext.cat[] to glue all the pieces back together. If this is a road you need to go down I can try to furnish a more detailed example if you clarify your requirements. The dialogizer demo deck uses rtext functions to build its index on the fly.

Does that help at all?

Sure- there are several ways to approach something like this!

The "in" operator can be used to check a string against a hardcoded list of valid options:

on click do
  if display.text in ("Keyword1","Keyword2","Keyword3")
   go[display.text "SlideLeft"]
  else
   alert["404: Page not found."]
  end
end

And it is also possible to obtain a list of valid card names from the deck; deck.cards is a dictionary from card names to cards:

on click do
  if display.text in deck.cards
   go[display.text "SlideLeft"]
  else
   alert["No such card, I'm afraid."]
  end
end

It might be a good idea to make the comparison case-insensitive if a user is typing free input. The easiest way to handle this would be to make sure the card names are all lowercase and then to convert the user input to lowercase with the "format" operator before doing any checks:

on click do
  t:"%l" format display.text
  if t in keys deck.cards
   go[t "SlideLeft"]
  else
   alert["I don't know anything about that."]
  ends
end

Yet another option is to make a dictionary to associate one or more keywords with destination cards; this provides more options for "forgiveness" in input handling:

on click do
  words["reindeerflotilla" ]:"puzzle1"
  words["reindeer flotilla"]:"puzzle1"
  words["reindeer"         ]:"puzzle1"
  words["smashthestate"    ]:"puzzle2"
  words["smash the state"  ]:"puzzle2"
  
  t:"%l" format display.text
  if t in words
   go[words[t] "BoxIn"]
  else
   alert["that's bogus!"]
  end
end

Does that make sense?

Could you describe what you're trying to accomplish in a bit more detail?

Is the idea that you'd just be stacking copies of images on top of one another repeatedly, or is it more like "gradually reveal a series of layered images"? Do you want this effect on a single card, or is it something you want to repeat in a variety of places with different images?

Hmm.

I suspect "tooted.value.1" should probably be "tooted.value~1" or even just "tooted.value", and you don't appear to be doing anything with the variable "c" or defining anything for the variable "o".

Dialogizer runs "synchronously", blocking most forms of input while its dialogs are open. You shouldn't be able to drag widgets around, click buttons, etc, while a dialog is open, but when you close the dialog and the initiating script finishes everything should be back to normal.

Is the problem that you want to drag the Interior while the dialog is open, or does it somehow cease working even after the dialog has been closed?

The default handler for the "loop" event provided by Decker looks like this:

on loop prev do
 prev
end

This handler is why the background loop plays forever by default; every time the loop ends, this function asks for the same sound to be played again.

If you write a deck-level script (File -> Properties -> Script...) which defines a replacement:

on loop do
 0
end

Then the loop will stop on all cards that do not have their own "on loop ... end" handler which overrides the above.

Does that make sense?

The number formatting issue has been patched in v1.37

Hm. Well, the first step (if you haven't done it already) would probably be stubbing out keyboard navigation, with a card- or deck-level script that overrides navigate[] to do nothing, to make sure the player can't accidentally go to your "protected" card without using editing tools:

on navigate do
end

Then you need some way of keeping track of whether cards have been "visited". Several ways to handle this. If you had an invisible checkbox on every card that needed to be visited named "visited", you could record visits something like so in each card's script:

on view do
  visited.value:1
end

Or even handle it automatically with a deck-level script fragment (not inside a function handler, just bare):

deck.card.widgets.visited.value:1

Left bare, it will execute whenever *any* event is processed. On cards without a "visited" checkbox it will have  no effect.

Check if every card with such a checkbox was checked using a query:

if min extract value..value where value from deck.cards..widgets.visited
  # ...
end

The ".." can be read as "at every index". The minimum of a list of 1/0 values is equivalent to logically ANDing them all together.

And you might want a button somewhere for resetting all the visited checks:

on click do
  deck.cards..widgets.visited.value:0
end

The nice thing about this approach is that as you add new cards in the future, you can decide on an individual basis whether they need to be counted toward "visiting everywhere".

Make sense?

Not currently.

If you're familiar with JavaScript it is relatively straightforward to install new primitives in the Lil interpreter by modifying an HTML build of Decker. This thread includes an example of exposing browser localStorage to Lil.

Async communication is somewhat awkward; if you were to expose an API based on callbacks, like the underlying JS APIs, you could easily end up with Lil functions attached via closure to parts of a deck that have been modified or destroyed since the original call was performed. A polling-based system exposed on an Interface might be less error-prone.

Here's a sketch (untested) of a polling-based wrapper for XMLHttpRequests:

const pending_messages=[]
interface_messagebox=lmi((self,i,x)=>{
   if(ikey(i,'send'))return lmnat(([url,verb,text,id])=>{
     const x=new XMLHttpRequest()
     x.onreadystatechange=_=>{
       if(x.readyState!=XMLHttpRequest.DONE||x.status!=200)return
       pending_messages.push(lmd(['text','id'].map(lms),[lms(x.responseText),id?id:NONE]))
     }
     x.open(verb?ls(verb):'POST',url?ls(url):'')
     x.send(text?ls(text):'')
     return NONE
   })
   if(ikey(i,'poll'))return lmnat(_=>pending_messages.length?pending_messages.shift():NONE)
   return x?x:NONE
})

WebSockets add some additional complexity because the connections need to be persistent, but a similar approach might work.

Widgets do not expose an attribute with a reference to the card that contains them. There are, however, several ways to accomplish what you describe.

Whenever a widget's event handler is fired, a number of variables will be in scope, including:

• "me": the recipient of the event
• "deck": the current deck
• "card": the current card (there's some additional subtlety to this in Contraptions, which I will omit for clarity)
• all of the widgets on the same card, according to their names
• all of the cards in the deck, according to their names

So, for example, your button script might look something like:

on click do
 me.text:card.name
end

If the button happened to be named "myButton" and the card it was on happened to be named "myCard" you could equivalently say:

on click do
 myButton.text:myCard.name
end

Another way to access cards is via the deck. The "deck.card" attribute is the card that the user is presently viewing. Generally this will be the same as the "card" variable, but "deck.card" might be more up-to-date if you happen to go[] to another card midway through a script. Thus, we could also write the example as:

on click do
 me.text:deck.card.name
end

The mechanics of events are described in more detail in the Decker Reference Manual.

Does that answer your question?

The ideal place to ask questions or submit bug reports about Dialogizer is the Dialogizer thread.

Rich text is represented as a table. While the "," operator applied to a pair of strings will form a list of strings, it will concatenate the rows of a pair of tables into a single table. We need to be a little more careful when we want to create a list of tables.

The "list" operator can solve this problem; it wraps any value in a length-1 list. The "," operator will join those length-1 lists together instead of the values they contain. Try constructing your list of choices for dd.ask[] like so:

(list field8.value),(list field9.value)

If the only special thing about the rtexts is the use of a single particular font, you could alternatively give the choices as plain strings and set the "bfont" option when you set up dialogizer; this will apply the specified font as the default for all the dd.ask[] choices:

o.bfont:"swedishFontName"
dd.open[deck o]
...

For general dialogs there's also "tfont" for the default font of the body text in dd.say[] and dd.ask[] boxes.

The go[] function is used to navigate to a different card.

There are three ways to specify the card you want:

• by index: if you provide a number n, go[n] will navigate to the nth card in the deck, counting from 0.
• by name: if you provide a string s, go[s] will navigate to the card with that name.
• by value: if you provide a card c, go[c] will navigate to the card you provided.

Navigating by index is usually not a great idea, because adding or removing cards can easily break such a script. We'll use navigation by value for these examples.

The numeric value of a slider widget can be viewed through its .value attribute.

To turn a numeric index into a card value, we'll make a list of cards and index into it using the slider's .value.

To slightly simplify your example, let's say you have a slider named "mySlider" with a range from 0 to 2, and cards named cardA, cardB, and cardC.

Forming a list:

(cardA,cardB,cardC)

Forming a list and then indexing it:

(cardA,cardB,cardC)[mySlider.value]

So the full button's script could be:

on click do
 go[(cardA,cardB,cardC)[mySlider.value]]
end

And of course, if you want a smoother transition you can specify go[]'s optional arguments for a transition style and delay:

on click do
 go[(cardA,cardB,cardC)[mySlider.value] "BoxIn" 15]
end 

This kind of approach also works if you don't need/want all the destinations to be distinct. Consider:

on click do
 go[(cardA,cardA,cardB,cardC,cardB)[mySlider.value]]
end

Is that clear?

The first example is very straightforward: widgets have a .toggle[] method. If you call it with a single argument it will alternate the value of their .show attribute between "none" and the string specified ("solid", "transparent", or "invert"):

on click do
  a.toggle["solid"]
end

You can see more examples of .toggle[] in the release notes.

Cycling through displaying several different widgets is a bit more complicated.

One approach would be to test the .show attributes of widgets, find which one is currently visible, and then set the .show attributes of all the widgets in a group in order to advance to the "next" selection. The main issue here is it's very ugly and inconvenient to add more widgets to the cycle:

on click do
  if     "solid"~a.show a.show:c.show:"none" b.show:"solid"
  elseif "solid"~b.show b.show:a.show:"none" c.show:"solid"
  else                  c.show:b.show:"none" a.show:"solid"
  end
end

We can reduce repetition and make maintenance a bit easier by making a list of widgets of interest, scanning for them in a loop, and using an index modulo the length of the list to pick the next item:

on click do
  cycle:a,b,c
  current:0
  each wid index in cycle
    if "solid"~wid.show current:index end
  end
  cycle..show:"none"
  cycle[(count cycle)%1+current].show:"solid"
end

If we want to get really clever, there's also a "vector-oriented" way to handle that search instead of an each-loop. In general, multiplying a list of integers [0,n) by a length-n list containing zeroes and a single one will "mask out" the index of the one:

(0,1,2,3)*(1,0,0,0)   # (0,0,0,0)
(0,1,2,3)*(0,1,0,0)   # (0,1,0,0)
(0,1,2,3)*(0,0,1,0)   # (0,0,2,0)
(0,1,2,3)*(0,0,0,1)   # (0,0,0,3)

So we could compute "current" like so:

Giving a complete script as follows:

on click do
  cycle:a,b,c
  current:sum(range count cycle)*"solid"=cycle..show
  cycle..show:"none"
  cycle[(count cycle)%1+current].show:"solid"
end

If you want to include "don't show anything" in the cycle, you can add a "0" dummy element to the list of widgets; 0.show will always be 0, which is not equal to the string "show", and attempting to set the .show property of a number is likewise harmless:

on click do
  cycle:0,a,b,c
  current:sum(range count cycle)*"solid"=cycle..show
  cycle..show:"none"
  cycle[(count cycle)%1+current].show:"solid"
end

Does that answer the question?

Edit: one more note: depending on what you're trying to do it might be worth considering using a slider widget instead of a button; Sliders naturally represent choosing between a range of integers, which could represent an index into a list:

on change val do
  cycle:0,a,b,c
  cycle..show:"none"
  cycle[val].show:"solid"
end

See also, the enum contraption.

The "in" operator can test whether a substring is present in a string:

 "upon" in "stars upon thars"
1

To use this on a column, we could define a helper function. While we're at it, this can also lowercase the column we're searching for a case-insensitive match:

on like needle haystack do
     each v in (list "%l")format haystack
         needle in v
     end
end

Allowing us to write a query like so:

ex:insert Date Entry with
     20210412 "Once Upon A Time"
     20220709 "There once were"
     20230101 "stars upon thars"
end
select where like["upon" Entry] from ex
# +----------+--------------------+
# | Date     | Entry              |
# +----------+--------------------+
# | 20210412 | "Once Upon A Time" |
# | 20230101 | "stars upon thars" |
# +----------+--------------------+

How's that?

The straightforward way is to use the "list" operator, which wraps its argument in a length-1 list:

 (list "foo") dict (list "bar") 
{"foo":"bar"}

A fancier, more concise way (provided your keys are strings) is to perform an amending assignment to an empty list, like so:

 ().foo:"bar"
{"foo":"bar"}

To obtain a list of the cards with a particular group number you could use a query something like

c:extract value where value..widgets.group.text=2 from deck.cards

(Note that if a 'group' field doesn't exist it will behave the same as a card in group "0"; you probably want to count from 1 for your groups)

Given that list, you can pick a random item and navigate to some card like so:

go[random[c]]

Or, all at once,

go[random[extract value where value..widgets.group.text=2 from deck.cards]]

Does that make sense?

You can adjust the widths of the columns of a grid to hide trailing columns. In "Interact" mode, a small draggable handle appears between column headers:

You can reset the columns to their default uniform spacing with the "Reset Widths" button in grid properties.

Manually resizing column widths enforces a minimum size. You can set column widths to 0 programmatically via "grid.widths", but a 0-width column looks a bit odd; I'll make a note to fix that in the next release.

Starting from the two fields you describe:

You can obtain the text of either field through its ".text" attribute. The "split" operator breaks a string on the right at instances of the string on the left and produces a list. Splitting one string on spaces gets us part of the way to what you're asking for. We can then use the comma operator to join a pair of lists.

" " split field1.text

The best way to experiment with this sort of thing is to use The Listener. Ask a "question", get an answer:

Another approach for gathering space-separated words from several fields would be to use an "each" loop:

Does that help point you in the right direction?

The Lil "comma" operator forms a list by combining the elements of its left and right arguments.

If you use this operator to combine a table and a number, the table will be coerced to its list interpretation (a list of the rows of the table, each a dictionary), and then combined with the number 1 (whose only element is itself), forming a list of several dictionaries and the number 1. Applied to such a list, random[] will occasionally choose the 1.

When you call a Lil function with multiple arguments, commas should not be placed between arguments. You probably meant

random[temp 1]

 Instead of

random[temp,1]

Furthermore, note that if you specify 1 as a second argument to random[] you will get a length-1 list as a result, whereas if you call random[] with only a single argument you will get a single value.

In preparing this post I have also observed that there is some inconsistency between native-decker and web-decker with respect to applying random[] to table values, which may have compounded the confusion; I'll have this fixed in the v1.41 release tomorrow. In the meantime the alternative is to explicitly crack the table into rows before making a random selection, like so:

random[(rows temp)]

Lilt uses a fixed seed by default; this is a design decision inherited from K.

One simple way to randomize it would be something like

sys.seed:sys.ms

Note that Decker automatically randomizes the RNG seed at startup.

In the context of query clauses, column names refer to the entire column as a list. The "where" clause expects an expression which yields a list of boolean values. Arithmetic operators like =, <, and + conform over list-list and list-scalar arguments.

Depending on how a predicate is written, it might naturally generalize to operating on lists for the same reason. For example: 

on iseven x do 0=2%x end
iseven[5]
# 0
iseven[11,22,33]
# (0,1,0)
extract value where iseven[value] from 11,24,3,8
# (24,8)

If a predicate is only designed to operate on a single scalar value at a time, you can use the "@" operator to apply it to each element of a column, like so:

on seconde x do x[1]="e" end
extract value where seconde@value from "Lemon","Lime","Soda","Demon"
# ("Lemon","Demon")

This shorthand is semantically equivalent to

extract value where each v in value seconde[v] end from "Lemon","Lime","Soda","Demon"

(And of course in this particular case the "like" operator would be simpler:)

extract value where value like ".e*" from "Lemon","Lime","Soda","Demon"

Does that clear things up?

Widgets have an attribute called "show" which controls their visibility; this can be "solid" (the default), "invert" (an alternate color-scheme), "transparent", or "none".

Suppose the button X is on card C1 and the button Y is on card C2.

You could give X a script for toggling Y's visibility:

on click do
 C2.widgets.Y.toggle["solid"]
end

Or a simpler version that just makes Y visible:

on click do
 C2.widgets.Y.show:"solid"
end

There are several other examples of doing this sort of thing in this thread.

To make clicking a button "unlock" dialogue or behavior elsewhere in the deck, you'll need to remember that the button has been clicked, and consult that record at a later time.

Checkboxes are just a special visual appearance for a button, so every button widget has a "value" attribute that can store a single boolean (0 or 1) value. Thus, we can use the button itself to keep track of whether it's been clicked. Suppose you've given the button Z on card C1 a script like so:

on click do
 me.value:1
end

A script on another card could reset Z's value,

C1.widgets.Z.value:0

Or test its value in a conditional:

if C1.widgets.Z.value
  # do something special
end

If you have lots of "flags" like this, it may be a good idea to centralize them in some kind of "backstage" card so you can keep track of them easily, and perhaps to give yourself a script for resetting the state of the deck.

Does that make sense?