Group Script to Manipulate Child Controls

[Lypny]

Hello everyone,

I've returned to LiveCode after a long hiatus.

I'm developing a desktop app to allow students to do multiple-choice tests and reviews at home as there will be no in-person lectures for the foreseeable future. For now, each card will contain a question with five answer choices, fields Answer A, Answer B, Answer C, Answer D, and Answer E in a group named Answer Choices. The group contains the handler chooseAnswer, which is invoked when a student clicks on one of the five fields, so each field contains the mouseUp handler

Code: Select all

on mouseUp pButtonNumber
   chooseAnswer
end mouseUp

The chooseAnswer handler in the group Answer Choices is

Code: Select all

on chooseAnswer
   if the owner of the target is not me then pass chooseAnswer
   else
      lock screen
      repeat for each line thisFldID in the childControlIDs of me
         set the backgroundcolor of field number thisFldID to empty
      end repeat
      unlock screen
      set the backgroundcolor of the target to "230,237,247"
      put the abbrev date && the long time & tab & \
            the short name of this card & tab & the short name of the target & \
            return after field "Log"
   end if
end chooseAnswer

You can see that, instead of using radio buttons, clicking an answer choice field changes its background colour and the choice is entered in a hidden log field. Works fine, but being a bit rusty, I'm wondering if I am missing a better way to go about this.

- Is the placement of the chooseAnswer handler within the group the best (whatever that may mean) way to catch the selected answer?

- The childControlIDs group property make it very easy to cycle through the child fields in the group. But what if I add other controls to the group that are not fields? Is there a way to parse the list of IDs into, say, buttons, fields, etc?

- What is the *Behave like a background* group property? Should that be enabled if I want the group to appear on each card, but the text (answer choices) contained in the child fields to be different as each card will be a different test question?


Any tips are much appreciated.

Greg

[jmburnod]

Hi Greg

- Is the placement of the chooseAnswer handler within the group the best (whatever that may mean) way to catch the selected answer?

If your group have Behave like a background to true, script of group is placed between cd script and stack script in the messages path

- ...Is there a way to parse the list of IDs into, say, buttons, fields, etc?

You may use a loop to build list of controls or get the num of flds, btns,img...of group

- What is the *Behave like a background* group property? Should that be enabled if I want the group to appear on each card, but the text (answer choices) contained in the child fields to be different as each card will be a different test question ?

You may even use one cd and import answers from a text file at preopencard and export user's results to a text file too at closecard

Edit: If you have only one cd you can't use preopencard but you may use a btn "nextAnswer" to import answers from a text file and export user's results to a text file too at closecard

Best regards
Jean-Marc

[dunbarx]

Hi.

When I get the feeling I am doing a lot of seeming extra and kludgy work, I give up.

No, no. I mean I rethink what I am doing.

I made a card with five locked fields, named "F1, F2...F5". I put some short text into each field. I grouped the five fields. In the script of the group:

Code: Select all

on mouseUp
   put the abbrev date && the long time & tab & the short name of this card & tab & target & return after field "Log"
   set the backColor of the target to "yellow"
end mouseUp

In the stack script (pseudo):

Code: Select all

on openCard
  clear the backColors of the group
end openCard

I don't know where your field "log" lives, and this might need some referencing. If there is only one group on a card, you can just loop through the fields directly, and clear the backColor.

Does this do everything?

Craig

[Lypny]

Hi Jean-Marc and Craig,

Thank you. Crystal clear and I believe I am getting my LiveCode legs back.

I have to give some thought to using one card and refreshing it with a new question as opposed to having one card per question. I guess the old HyperCard paradigm would be many cards. I figure that many cards wouldn't be that much less efficient since searches across cards will not be allowed and there would be at most 100 questions. Storing the questions and answer choices as an associative array in a custom property is appealing because associative arrays can be accessed so quickly. Years ago there was a good discussion on the merits of one versus many. Wonder if I still have it on my machine.

Thanks again,

Greg

[dunbarx]

Great. Get going.

It seems that simply placing that mouseUp handler in the stack script would do, no? And then why group at all, unless it is convenient to create new cards, with the group's backGroundBehavior set.

As for whether you might have one card per set, or a single card that you load with sets pulled from, say, a custom property or simply all hidden on the card and made visible as needed, that is a matter of personal style.

Craig

[Lypny]

True, the app isn't complicated, the paths short. Probably easiest to put many of the handlers in the stack script.

Greg

[dunbarx]

Since you are an old HC'r, like many here, know that HC really did not care if you had a stack with many thousands of cards. It did not impede searches or general navigation at all.

But LC starts to bog down significantly after a few thousand cards. That is why many use an external file to hold that sort of data, and load from there.

Craig

[mrcoollion]

But LC starts to bog down significantly after a few thousand cards. That is why many use an external file to hold that sort of data, and load from there.
Craig

This post on how I save and retrieve data (encrypted or not) might be of interest.
viewtopic.php?f=12&t=33338#p185397


Paul

[jacque]

The childControlIDs returns the short ID of each control so technically the repeat loop should reference "field ID" rather than the number. I'm surprised it worked when referring to the number but I guess LC is more forgiving than I thought.

The name of the function gives a clue as to how to reference objects that aren't fields ; "control" is nonspecific. This would allow you to scan any type of control in the group:

Code: Select all

     repeat for each line thisID in the childControlIDs of me
         set the backgroundcolor of control ID thisID to empty
      end repeat

I think it's fine to have the handler in the group. The usual advice is to keep handlers as close to the things they work with as possible.

[dunbarx]

Jacque wrote:

The usual advice is to keep handlers as close to the things they work with as possible.

Surely can be convenient when one suddenly needs to debug; the script that likely holds the handlers of interest is close by.

Craig

[Lypny]

Since you are an old HC'r, like many here, know that HC really did not care if you had a stack with many thousands of cards. It did not impede searches or general navigation at all.

But LC starts to bog down significantly after a few thousand cards. That is why many use an external file to hold that sort of data, and load from there.

Craig

Yes, I am aware that LC slows when a stack contains many cards. The card metaphor is intuitive and robust, too bad about the slowdown. I have used approaches similar to Paul's when processing a lot of data. Reading and writing data files, along with associative arrays, worked well for merging data on gene sequences with references databases on the web.

Greg