LiveCode Forums.

HJay,

I'm glad you're bearing up well under all my questions. From the point of view of a programmer, computers are basically "stupid," i.e., they will only do exactly what you tell them to do. So it really pays to figure out exactly what you want (or more precisely what you need) to happen, in advance of doing the actual programming. Otherwise you find yourself needlessly rewriting parts of your program as you realize that you need this or that to happen at some point.

I think we're very close to starting the review what you've already coded to see what else needs to be revised or added. I believe that you've already finished the bulk of the program -- but we still have some work ahead.

The only outstanding question I have at this point relates to the recording and ultimately reporting of the students right and wrong answers. Because you want to record all the answers, you need code for this right from the very first card displayed. So it needs to be decided now.

I can think of multiple ways to record and print the results. The simplest, and to my mind, probably the least useful, would be to literally record and print the exact series of numbers shown and which number was chosen:

4 - 6 or 4 - Correct
7 - 7 or 3 - Correct
5 - 6 or 5 - Wrong
etc.

There could be a summary at the end, which could be broken up by each digit, or just an overall percentage of correct/incorrect answers

Perhaps a step up would be to sort the numbers beforehand:

0 - 0 or 2 - Correct
0 - 3 or 0 - Correct
0 - 5 or 0 - Correct
.
.
.
9 - 3 or 9 - Wrong
9 - 9 or 8 - Correct

Again followed by a summary.

If you don't need to see the exact sequence of numbers displayed, you could do a ten by ten grid (0 to 9 on both top and side), and at the intersections display the percentage correct for that combination.

Obviously, the next step up from here would be to show a graph of the results. Off hand, I can't think of any built-in commands for LiveCode that would aid in displaying a graph, so a graph might get a little tricky to code (although I'm sure it could be done). It's something that would need to be researched -- to see if someone else has already done it, in hopes that we could beg, borrow, or steal the code. (Smile.)

You should also decide if some way needs to be provided to enter the student's name on the print-out -- and perhaps the date and time, as well. (Or maybe some blank lines could be added, where the name and other info could be handwritten on the print-out.)

As soon as you settle on what you need in the way of reports, the final work can begin on your program.

Hi AtoZ

Your right the pupils name and the date would be really useful on the print out.

I need to have the record of their answers in the order it was answered, would it be possible to display like this:-

FR1 1 Click the 9 9 – 0 answer 9 correct

R/Y 1 Click the 5 3 - 5 answers 5 correct Red 5p

FR20 1 Click the 7 9 – 7 answer 7 correct
FR20 2 Click the 8 9 – 8 answer 8 correct
FR20 3 Click the 2 9 – 2 answer 9 incorrect
FR20 1 Click the 5 5 – 7 answer 5 correct
FR20 2 Click the 0 9 – 0 answer 0 correct
FR20 3 Click the 3 3 – 7 answer 3 correct
FR20 4 Click the 6 9 – 6 answer 6 correct
FR20 5 Click the 9 9 – 7 answer 9 correct
FR20 6 Click the 1 1 – 7 answer 1 correct
Etc. etc.

G/B 1 Click the 3 1 – 3 answer 3 correct Blue

Could the R/Y and the G/B be the way round that the colours were presented? Could they be in colour i.e. R/Y G/B that would be really useful?

I love graphs but in this case I don’t think it is necessary.

Many thanks

HJay

I've updated the flowchart to reflect your latest decisions. We're now up to version 2.5. Let me know if you want to make any changes.
So I think it's finally time to start writing code again for your project! I'm going to leave as much of the coding as possible to you (it's the only way to really learn the program), but I'll be happy to help when you get stuck.

The first thing is to collect and store the student's name. The code for this should be added to your start button script before the code that sends the pupil to one of the FR cards. As usual, there are multiple ways to do this, but I think the easiest would be to use the ask command. (If you've not used the ask command before, read up on it in the dictionary and the user guide).

I assume that you will want to use the question icon. The displayed message in the dialog box should be directed to the teacher, asking him or her to enter the student's name. Do you need first and last names? If so, tell the teacher that (along with the order to enter the names). In the line immediately following the ask command, insert a line of code that reads "put it into gStudentName" or whatever global name you want to use. You'll use this at the end of the program when you print out the results.

You can also use the student's name in other places in the program if you wish, such a when you show the "Oops..." dialog: "Oops, you clicked on the wrong number. Try again, Mary." (You can extract just the first word of the name from the global by using "word 1 of gStudentName"

Although you'll collect the student's name at the beginning of the program, I think it makes more sense to retrieve the date and time at the end of the session. You can get this info from the computer being used. Before we get to revising the code for the Finish card, you should read up on the date and time capabilities of LiveCode.

When you reply next, please attach the latest version of your stack, so that we'll both be looking at the same code.

Hi AtoZ

Flowchart Ver 2-5 looks perfect.

Am now off tor read about the ask command

Talk soon

HJay

Hi AtoZ

Have just managed to get back to my program. Have had an inspection at school!!!

Well here is what I have done...

Have added a name card to the front of the stack and worked out how to use the ask command all on my own! Yay!

Have also managed to record the date and time at the start and also hope to record the date and time at the end of the program so then will be able to work out how long it took altogether.

I don’t know what you mean when you talk about the “question icon”?

What shall I do next?

Many thanks

HJay

Having trouble posting attachment

Seems to have worked this time?

Because there are a number of issues that I want to address I'm going to break my response into several posts.

-----

First, no problem about the longish delay for you to get to your last post. I'm retired, and I have all the time in the world (if you ignore the larger question of how much time I have left on this world -- smile).

What I don't know though is your schedule for completing this project. So:

Is there a deadline for finishing this project?

Also a couple of other more or less unrelated questions that I've had hovering in the back of my mind:

Do you plan to compile this stack as a standalone program, or will students be using it within the LiveCode evnironment?

What version of LiveCode are you using?

If you're not sure, open LiveCode, and select "About LiveCode" from the "Help" menu. Your version number will appear in the upper-right corner of the window that opens. (For example, I'm using Version 5.5.0.) Click on the About window to make it go away.

-----

Next, I want to address a couple of issues that I believe will make finishing this project easier for you:

I suggest you open the Preferences for LiveCode (at the bottom of the Edit menu), and make three changes:

1. Click on the "Files and Memory" section in the left panel. In the first entry at the top of the section, click on the option that reads "Close the file".

2. In the same "Files & Memory" section, turn on the option (4 or 5 lines down) that reads "destroyStack property is set to true for new stacks"

Doing these two things will help you avoid having multiple copies of the same stack open at the same time for all NEW stacks that you create. However, it won't affect your current stacks, nor will it affect other uses of your stack who do not have this option checked in their LiveCode preferences.

To fix this, you should add the following line of code to the "on closeStack" routine in all your main stacks (it should be put in your stack script):
If don't have an "on closeStack" routine yet in your stack (which you don't at this point), then this is the time to add it and let the above be the first line of code in it.

Please note that this command does NOT erase your globals (and the information stored in them) from memory. Those will remain in memory until you close LiveCode. This is normally not a problem, but just be aware that your globals don't go away when you close a stack. There is a way to remove your globals from memory, but to do it properly gets a little complicated, and we won't deal it unless some problems pops up along the way to force our hand.

Because we're clearing the stack from memory when we close it, any information that needs to be saved between uses of the stack, will have to be saved before the stack is closed (info can be saved in fields -- either hidden or visible, custom properties, or external files). You've already done that with the 90 possible pairs of single digits (bravo), and if anything else comes up that we need to save, we can take care of that too.

3. Now, go back to Preferences, and click on the "Scripts Editor" option in the left panel. And choose the option to turn on the "Strict Compilation Mode" option. This option means that every time you compile or save your scripts, LiveCode will tell you if you have any undeclared or misspelled variables.

If this had been turned on when you wrote your latest script for the "Name" button, it would have pointed out that you had not declared the gStudentName variable.

In addition to putting a red dot next to the first line of code in your script that uses this global, it also displays a less-than-clear error message below your script:

"button "Button": compilation error at line 5 (Chunk: can't create a variable with that name (explicitVariables?)) near "gStudentName", char 11"

The key words from this error message are "explicitVariables" and "near gStudentName".

What it's saying in somewhat plainer English is: "LiveCode stopped compiling this script because it encountered a variable (gStudentName) that you have not previously declared."

This setting also helps catch misspellings of variable names. (If you type "gSutdentName" but declared gStudentName, you'll get the error message.)

Turning on this option also means that you will have to declare your local variables before using them, just as you do globals.

Turning on this option may seem like it's making extra work for you, but in the long-run I believe you'll find that it saves time later on -- when trying to figure out why a script isn't working because you've forgotten to declare a variable or misspelled a variable name.

-----

While you're in the "Script Editor" panel, you may also want to:

1) Enlarge the size to the font used to display scripts (although your eyes my not need this) -- it's at the top of the section.

2) Increase the size of script indentions to 4 -- at the bottom of the section -- to help make the structure of scripts a little clearer.

3) Change the font used to a mono-spaced font such as Courier or Liberation Mono (my choice). Changing the font is purely my personal preference -- I like a mono-spaced font here because it helps me align the side comments that I insert next to my code.

-----

In my next post, which will come shortly, I'll start to address some of the things specific to your latest version of your program.

OK, onto part two of my comments about the current version of your stack.

-----

Let's go through your code for the "Name" button:
Congratulations on figuring out how to use the ask command. We'll probably be using it again later in the stack.

There are several things to note about your code:

-- As I pointed out in my previous post, the variable gStudentName was inadvertently left out of the global declaration at the top of the script.

-- You declare both a gDate and gStartingDate at the start of the code, but only use gDate. I suspect that gDate was a first effort, and that you later decided to use gStartingDate but forgot to update the rest of your code. But more importantly, if you're going to time the session, this is not the place to start the timer. Remember that the next card is the Start card, and you say at the top of that card, "When your ready click start." Clearly, when the student clicks on the Start button would be the place to start the timing.

A side note that I was going to bring up when we get to the Start card, is that you should correct the not uncommon error of using "your" for "you're". The label should read: "When you're ready, click Start" (I would say, "When you're ready, click the Start button below", but, as you've no doubt noticed, I tend to be long-winded.) The added comma is optional for a short phrase like this, but I think it more accurately reflects the way one would read the label out-loud: "When you're ready (short pause) click Start"

A final comment about timing a session: Such timing can only be approximate because it is difficult (if not impossible) to deal with possible interruptions of the session (such as events happening around the students that might distract them from the session, pausing to ask the teacher a question, bathroom breaks, etc.). There are things that could be done to minimize this (for example having teachers closely monitor the session, perhaps adding Pause/Resume buttons, etc.). But it may not be worth the effort for the usefulness of the information obtained. It's your call, just be aware of the limitations.

-- Congratulations on introducing some basic error checking into you code when you check to make sure that the field in the ask dialog has not been left blank. I believe that from the students' view, you could improve on this by letting them know why they are not proceeding. As usual, there are several ways this could be done. Here's one way: replace the line that reads "go to card 1" with the following code that includes an explanation of why they're seeing it:
By putting the ask code inside the repeat loop, you ensure that the student cannot proceed until they have entered something. (Please note that that something may not necessarily be their name, which is why I specifically ask them to type in their first and last names – not that this will in anyway guarantee that they will use their real name, all you can do is try). Once something has been entered, they are moved to the next card.

You can, of course, use the wording of your choice for the ask command.

In case you haven't encountered it before, the “cr” in the ask command stands for “carriage return” and it's used to force a line break wherever you need one. Note that it stands by itself without quotes marks and is preceded and followed by an ampersand. (The backslash at the end of a line, allows you break a long line of code into two shorter lines.)

-----

This brings me to another potential problem (depending on your preferences): In an earlier post, I had indicated that you could put in code later in the stack to personalize the session, for example:
The problem with this is that it doesn't deal well with two-word first names (such as Mary Beth or Le Roy). If you don't feel that personalization is needed, then there is no problem with the way you've setup the Name card. But if you want to personalize your later messages, then we need to do things a little differently. So that's my next question for you:

Do you want to personalize your messages later on in this stack?

If you do, I'll suggest a different, but still simple, way to handle it on the Name card.

-----

Now, a comment about your use of "go to card 1" and "go to card 2". The code works in your stack now, because card 1 is the Name card and card 2 is the Start card, but if you ever have occasion to insert another card before either of these cards, it will no longer work. You also have to know what card 1 and card 2 are in order to understand where the code is sending the student. It's better to avoid using card numbers and instead use the card names:
-----

So in the end, I suggest that your code for the Name button look something line this:

global gStudentName
Although you could, of course, copy the above code and paste it into the script for your “Name” button, I urge you not to do this. Instead, copy it and paste it into a word processing program (like Notebook or Word, or LibreOffice) and print it out. Then go to your script for the “Name” button and manually change your code yourself (including changing the wording of the ask commands as you prefer). Think about each line as you enter or correct it, and make sure that you understand why it’s there. You need to become comfortable with the meaning of every line of code you write. With a few exceptions, nothing you put into your scripts should be a mystery (or magic as we talked about earlier). In my opinion it’s the only way to become comfortable with using LiveCode.

-----

That's enough for now. My next post (in a day or two) will continue with a few suggestions for the
text that appears on the Name card.

Hi AtoZ

Sorry my last post didn't post??

Am going to print out the instructions, so I can tick off changes as I go along. Will hopefully post later.

Many thanks as always

HJay

Hi AtoZ

Is there a deadline for finishing this project?

Well, I would really like to be able to have a go at running the training phase (which is what we are working on now) followed by the testing phase (which is another separate program, which I hope by the time I have learned how to program the training phase, will be easy (smile) by the end of the academic year. That is I would really really like to be able to start this on the 2nd of July.

Do you plan to compile this stack as a standalone program, or will students be using it within the LiveCode environment?

I would like this stack to work as a standalone program. I would also like there to be no obvious way of terminating the program half way through. Is this possible? I guess there would need to be a keyboard short cut to terminate if the teacher needed to though?

What version of LiveCode are you using?

I'm using Version 5.5.0.


I have followed all of your suggestions and have also added the missing gStudentName

I do like the idea of being told when I have spelt a variable wrong, I am a rubbish speller and have already wasted lots of time by spelling things wrong.

The only thing I haven’t done is change the font to mono; I have used century gothic as it is a font I find easy to read. I am dyslexic hence the rubbish spelling if I use a font with serifs or fonts that don’t sit together I end up looking at the white space rather than the text as it starts for form patterns. So hope you’re ok with century gothic?

-- You declare both a gDate and gStartingDate at the start of the code, but only use gDate. I suspect that gDate was a first effort, and that you later decided to use gStartingDate but forgot to update the rest of your code. But more importantly, if you're going to time the session, this is not the place to start the timer. Remember that the next card is the Start card, and you say at the top of that card, "When your ready click start." Clearly, when the student clicks on the Start button would be the place to start the timing.

Yes of course, doh! Have moved gStartTime to the start button and got rid of gDate completely.

A side note that I was going to bring up when we get to the Start card, is that you should correct the not uncommon error of using "your" for "you're". The label should read: "When you're ready, click Start" (I would say, "When you're ready, click the Start button below", but, as you've no doubt noticed, I tend to be long-winded.) The added comma is optional for a short phrase like this, but I think it more accurately reflects the way one would read the label out-loud: "When you're ready (short pause) click Start"

It is done (smile) please feel free to correct/point out my spelling, grammar and coding, they are all lacking!

A final comment about timing a session: Such timing can only be approximate because it is difficult (if not impossible) to deal with possible interruptions of the session (such as events happening around the students that might distract them from the session, pausing to ask the teacher a question, bathroom breaks, etc.). There are things that could be done to minimize this (for example having teachers closely monitor the session, perhaps adding Pause/Resume buttons, etc.). But it may not be worth the effort for the usefulness of the information obtained. It's your call, just be aware of the limitations.

Yep, the teacher will be instructed to keep pupils on task as far as reasonably possible. Am quite happy with a rough idea of the time taken.

I have changed the wording a bit to make is simpler, I also don’t need a surname, we only have 11 pupils in the school. I have though made a note of ‘cr’ etc.

Do you want to personalize your messages later on in this stack?

I don’t need personalised messages in the stack. I think that it would limit the usefulness of the program at the moment. I would also like to keep things as simple as possible for me as well, while I am on such a steep learning curve

Now, a comment about your use of "go to card 1" and "go to card 2". The code works in your stack now, because card 1 is the Name card and card 2 is the Start card, but if you ever have occasion to insert another card before either of these cards, it will no longer work. You also have to know what card 1 and card 2 are in order to understand where the code is sending the student. It's better to avoid using card numbers and instead use the card names:

Very good advice, which I have followed


Rather than copy and pasting the code, I opted for even more low- tech solution and printed out your posts and typed in the code as I worked out what I was supposed to be doing. I just love it when the words change colour, it also makes me double check my spelling and puts the indents in the right place.

Many many thanks for your observations etc. Have attached the current version of the program. Hope it is correct?

HJay

AtoZ wrote:As they say, there are many ways to do things in LiveCode.

I like this way. I was about to post with a firstLeft and allLeft starting at 10 and 20, then the random(allLeft) doing the first card if <= firstleft, and the second otherwise, but this has an elegance to it.

I still can't get rid of my ancient habits of conserving every bite and machine cycle, learned in the days they were precious . . .

Thanks, docHawk.

As you noticed, several different ways were propsosed to do this, some of them quite complicated. I just chose to model it the way I would do it in the real world: Throw 10 copies each of the two card names into a bucket and then draw them out one at a time.

Simple is best -- if other factors do not need to be considered.

HJay,

Sorry for the delay in responding. I was dealing with some health issues that now appear to be resolved -- or at least mitigated (nothing too serious).

Hopefully we'll be able to meet your desired finish date. We could probably finish it up in an afternoon if we were working side-by-side, Doing it this way is painfully slow, especially having to write out long explanations that in the real world could be done by just sitting at the computer and showing you in just a few seconds or minutes. But what we have, is what we have.

Although there are a number of "graphic design" issues that I would like to go over with you, to help improve the look of your stack, I'm going to resist that for now, and focus instead on getting a working program going. Once we have that, we can hopefully spend a little time on improving the looks of the stack.

With regard to the font you use for your scripts, that is purely your personal preference -- I will never see it -- when I open your scripts they display in the font I've selected for my scripts, so feel free to use whatever font seems best for you.

Back to the stack:

NAME CARD:

The script for the Name button is OK now.

START CARD:

As I was reviewing the stack, I noticed something that we need to sort out. When a student finishes either of the color cards, the scripts for these cards currently sends the student back to the Start card, where he or she has to click the Start button again to begin the next cycle. Is this what you want? The alternative is to send the student directly to the next FR1 or FR20 card.

As I go through using the stack, it seems confusing to me to be confronted with the Start button again repeatedly, since I've already started some time ago. If you DO want the student to click a button each time he or she begins a new cycle, perhaps it would make more sense to change the Start button to a Continue button. This would work even the first time since the student is now coming from the Name card and has in a sense already begun the stack.

If you want to return to the Start card each time, we need to make a modification to the Start button script to avoid resetting the start time each time the card is opened. This can be done with two simple steps:

1. Change the Start button script as follows:
2. Remembering that globals are not normally cleared between uses of a stack (unless LiveCode is closed), we need to ensure that gStartTime, and some other globals as well, are in fact empty the first time we go to the Start card. To do this, go to the stack script and add the following code at the top of the script:
We will probably be adding other globals to this script as we proceed.

(While you have the stack script open, I suggest that you open the Stack Inspector, and change the Title entry for the stack from “Home” to either “Matching Numbers” or “Work Ethic”. The title entry is the name that appears in the title bar of the stack window. The word “Home” does not seem very helpful here.)

Finally, if the student is to go back to the Start card for each cycle, I will need to revise our flow chart again to reflect this (no problem).

I expect to post a couple of more messages regarding the project later today.

HJay,

In this post I want to deal with your request to provide a discrete way for the teacher to get out of the program. In thinking over the various options, I decided the easiest way would be to insert code in the stack script to respond to the teacher pressing the "e" (for exit) key while holding down the Ctrl key (otherwise known as the command key).

I'm not sure if you want this action to reset the stack back to the start so that a new user could begin, or if you wanted it to exit the stack. I'm showing you here how to do the first option. If you want to exit instead, just let me know, and we'll modify the code to do that.

The first thing to do is to go to your stack script and insert this handler after the openStack handler:
With one exception, I think that this code should be fairly self-explanatory: If the teacher holds down the Ctrl key and presses the "e" key, the script immediately goes back to the Name card and (this is new) resets the stack to begin again. So what is this "uNewSetup" command? It's a little custom handler that we're adding to the stack script and it looks like this:
The three lines of code inside the handler should look familiar to you because I had you add them to the openStack handler in my last message. In general, one wants to avoid duplicating code, not just because it might save a little typing time, but more importantly because if you have code in only one place, there is only one place you need to go to in order to fix or add to that code. This applies here, so what you should do is revise your openStack handler as follows:
To summarize, your stack script should now look like this:
I'm sure as we go along that we will be adding other things to the uNewSetup handler, as well as the stack script itself.

----

One last thing in this post that I've been meaning to ask, but keep forgetting to do so:

On all the number matching cards (FR1, FR20, R/Y and B/G) you've added little fields around the margins that show the card name, number of cards shown, etc. Some of these are working correctly and others need to be revised to work right. My question is, do you intend to keep these side fields in the final version or are they temporary in order to check that you code is working properly? Either way is fine with me, but I'd like to know which way you're planning to go with them. Thanks.

Well, I've discovered that we need to make one small change in the code I send you for resetting the stack. We shouldn't use Ctrl + e because it overrides the LiveCode command for opening an object script when you're in the "edit" mode. Instead, let's use Ctrl + r (for reset). In the handler that we added for this in the stack script, just change "e" to "r":
When choosing which keys to "trap" with your code (which is what this is usually called), you should always check to make sure that the selected keys do not override any built-in commands. I actually did this, but I only checked it while in the "run" mode. I forgot that scripts in LiveCode remain live even when you switch to the "edit" mode, and in the "edit" mode, Ctrl+e is used by LiveCode. I've checked Ctrl+r in both modes, and it appears that it is available for use. Sorry about the confusion.

Since I'm here again, let me take this opportunity to make a design suggestion:

In the "edit" mode, select any of the buttons used in your stack (such as the "Name" button or the "Start" button) and then choose "Icons & Borders" from the Object Inspector drop-down menu. Near the bottom of those options, change the "Border Width" to 8 and press the Enter key to register the change. Then click outside the button to unselect it and look at the result. I believe this makes the button look more like a button, and would suggest making this change for all of the buttons in your stack that look similar to the "Name" and "Start" buttons (including the number buttons on the FR1, FR20, R/Y and B/G cards). Let me know what you think. (And it's no problem if you don't like it.)