Could you post the scripts you're trying that work and those which do not work? It's much easier to diagnose problems with scripts when I can read them and clearly understand what you have tried.
of course! I've tried a few things so far, at the card level. below are the checks I've tried, and neither have worked.
while view if blueFrame.value:1 & pottedPlant.value:1 & bookStack.value:1 dd.open[] dd.say["The code worked!"] dd.close[] else end end
if blueFrame.value:1 pottedPlant.value:1 bookStack.value:1 dd.open[] dd.say["The code worked!"] dd.close[] else end end
below is the code I have in blueFrame. it's nearly identical in the other two objects, with just the dd text changed
dd.open[deck] dd.say["(Something's tiny femur is displayed in this frame.)"] dd.say["(I should ask the professor what creature this belonged to.)"] blueFrame.value:1 dd.close[]
and this is the code in the title card that sets the values to false if they aren't already.
on view do cardOffice.widgets["blueFrame"].value:0 cardOffice.widgets["pottedPlant"].value:0 cardOffice.widgets["bookStack"].value:0
thanks for your quick reply!
Let's start with a few basics.
In most cases, scripts on widgets, cards, and the deck should consist of a series of event handlers. Event handlers are written as an "on ... do ... end" block, like so:
on click do # more code in here end
Decker will automatically create some "stub" event handlers like this when you initially edit the script of a widget or card. If you write code OUTSIDE of an event handler, it will be executed EVERY time ANY event occurs, which can cause odd and surprising misbehavior. None of the scripts you have included here have a well-formed "on ... do ... end" block around them.
---
In the "if ... else ... end" conditional structure, the "else" portion is optional. If there's no alternative:
if someCondition # some code else # nothing end
You can leave off the "else" half:
if someCondition # some code end
---
The colon (:) symbol is Decker's assignment operator. In simple cases, it assigns values to variables:
myVariable:42
And in more complex cases it can also be used to assign to attributes of interface values, like the "text" attribute of a field widget:
myField.text:"Some Text"
In several of your scripts you seem to be using colons as if they were a equality operator. If you want to check whether an attribute of a widget matches a number, you may want the "~" operator:
if blueFrame.value~37 ... end
As I explained in the previous thread, a conditional which checks multiple conditions should wrap each "clause" in parentheses so as to apply an intuitive order of operations:
if (blueFrame.value~1) & (pottedPlant.value~1) & (bookStack.value~1) # some code end
But when you're specifically checking whether a flag is "truthy" you don't need to compare anything to 1; the above can be simplified to
if blueFrame.value & pottedPlant.value & bookStack.value # some code end
---
Let's say your title card's "view" event handler resets the value of the three buttons on the card cardOffice:
on view do cardOffice.widgets.blueFrame .value:0 cardOffice.widgets.pottedPlant.value:0 cardOffice.widgets.bookStack .value:0 end
Each button should have a "click" event handler which sets the button's value to record the click. We can then also have those event handlers call an event handler defined on the card which acts as a centralized place to check whether every button has been clicked. Let's call our "synthetic" event "checkObjects". As a convenience, within a widget's event handlers you can refer to the widget itself as "me". The whole script could look something like:
on click do dd.open[deck] dd.say["(Something's tiny femur is displayed in this frame.)"] dd.say["(I should ask the professor what creature this belonged to.)"] dd.close[] me.value:1 checkObjects[] end
Then we'll need to define that "checkObjects" handler within the card script:
on checkObjects do if blueFrame.value & pottedPlant.value & bookStack.value dd.open[] dd.say["The code worked!"] dd.close[] end end
Does that help point you in the right direction?
yes, this absolutely does! I just tried it out, and it worked! I had to move the checkObjects event call below dd.close[] (I think since the check initiated a dialogue box), and that finally did it. thank you so much for your help. I'm learning something new all the time while tinkering with this, and its been a lot of fun.