Hilighting Buttons

[chelling]

I can’t get this solution and will appreciate help. I have a set of buttons any of which may or may not be visible. If the user types 1, then the highlight of the next visible button should be true and the current highlight false.

This works to advance the hilite to the next button if all of them are visible:

on stepOn
if gwhichButton < 1 then StartStepScan
else
set the hilite of cd btn gwhichButton to false
add 1 to gwhichButton
if gwhichButton > 10 then put 1 into gwhichButton
if the environment is "mobile" then play specialFolderPath("engine") & "/audio/typekey.mp3"
set the hilite of cd btn gwhichButton to true
end if
end stepOn

Does anyone have any suggestions on how to advance directly to the next visible button?

Thanks!

[dunbarx]

Hi.

Odd way to invoke that.

Put this into your field script. I assume that the suite of buttons you are interested in are grouped. Are they? They should be, as this simplifies a whole lot of object referencing. In the example, the buttons are in "grp 1". Start with at least one button hilited.

I leave it to you to find the two problems this contains, and to fix them. There is a hint in the above for one of them.

Code: Select all

on keyDown tKey
   if tKey = "1" then
    get  the number of btn the hilitedbutton of grp 1
      set the hilite of btn it of grp 1 to "false"
    set the hilite of btn (it + 1) of grp 1 to "true"
 end if
 pass keyDown
end keyDown

Write back if you need help.

Craig Newman

EDIT:

I reread your post and saw the thing about the next "visible" button. So now do this:

Code: Select all

on keyDown tKey
   if tKey = "1" then
      get  the number of btn the hilitedbutton of grp 1
      set the hilite of btn it of grp 1 to "false"
      repeat with y = it + 1 to the number of btns of grp 1
         if the visible of btn y of grp 1 then
            set the hilite of btn y of grp 1 to "true"
            exit repeat
         end if
      end repeat
   end if
   pass keyDown
end keyDown

Same two problems, though.

Craig Newman

[chelling]

Thanks John. I actually think you have helped me with this before and I can't tell you how much I appreciate it. I didn't explain this very well. I have been working on this problem and I think I am fog brained at this point.

This is an application for a child who is unable to use their hands to use a computer. In this case, one switch is used to advance the button hilites. This switch will input the number one (1). A field is used to monitor input. When the #1 is received, the current button will turn off the hilite, and the next button will hilite. To make a selection, the user presses a second switch which sends the number three (3). This triggers a "send mouseUp".

With these kids, it can be very, very helpful if the teacher, therapist or parent can select which vocabulary to start with, and then gradually introduce new items. Hence, this is where the hide/show or visible/not visible comes in to play.

I have a custom property set up "scannable" that can be true or false. Buttons with false scannable are hidden. Buttons with true are visible and targets to be scanned. With one switch scanning where the #1 key input is the selector, I was able to use "next repeat" and it works. I can't get this to work at all with the two switch scanning.

I have attached a sample. In this case, buttons 1, 3, and 9 have scannable set to false.
Thanks again.

[dunbarx]

Who's John?

What are you using as switches? I have done a bit of work with gadgets that interface the outside world with a computer, using LC as the front end.

Craig

[chelling]

Sorry Craig - more of that brain fog. This is an example of the types of switches commonly used. http://www.ablenetinc.com/Assistive-Tec ... -Big-Buddy
They are used to provide input as assistive technology devices. With computers and mobile devices, there is an typically an interface between the computer to provide the hardware connection as well as to set what the input will be. With computers, sending a mouse click is very common. With iOS, the interface has to emulate a BT keyboard, and that is why I am trapping 1 and 3. This is pretty standard for applications written for this purpose.

[Randy Hengst]

I'd suggest naming the buttons differently ... naming a button "Button 1" can confuse the engine (and you) when you're moving from one to anther using the cd btn number... You can easily change the button label as needed to communicate what you need to for the user. In my suggested change to your handler, the buttons are named ScanButton1, ScanButton2, etc.

on stepOn --Works with all buttons visible.
if gwhichButton < 1 then StartStepScan
else
set the hilite of btn ("ScanButton" & gwhichButton) to false
add 1 to gwhichButton
if gwhichButton > 10 then put 1 into gwhichButton
if the environment is "mobile" then play specialFolderPath("engine") & "/audio/typekey.mp3"
if the visible of button ("ScanButton" & gwhichButton) then
set the hilite of btn ("ScanButton" & gwhichButton) to true
else
add 1 to gwhichButton
if gwhichButton > 10 then put 1 into gwhichButton
set the hilite of btn ("ScanButton" & gwhichButton) to true
end if
end if
end stepOn

randy hengst

[chelling]

Thanks Randy,

The stack I attached is not the real application – just one I put together to help me figure out how to skip buttons that are not visible and have the scannable custom property set to false.

gwhichButton is a global variable that holds the number of the currently hilited button. The problem I am having is that the scanning doesn’t skip the invisible buttons. It will still step on to the next button in the sequence – even though it doesn’t hilite. So, the feedback to the user is that the scanning has stopped.
Is there a way to determine the “next scannable button” from any given button number?

Celeste

[Randy Hengst]

Hi Celeste,

The suggestion I made to your handler does what I understood to be your question. It's not specifically using the number of the button (which is assigned as they are made and will change if you change the layer). If you use my version of the handler, and hide some buttons, they will be skipped.

be well,
randy

[chelling]

Now I get it. You are concatenating the button number to the button name. But, what if in the actual application the buttons are named in a way that lets me get the short name of the button, put it into a variable, and then go to that card? So the buttons won't have the same name? Should I add a common word 1 of the short name of the button?

[Randy Hengst]

You could do that... but I'm not sure what you're doing when the user activates a button. I usually name my buttons as one word ScanButton1, for example. You can use the same button names on every card, then in the script refer to the ScanButton1 on card "HouseHoldItemsCard"

I haven't really ever used background groups... others on the list and forum can be helpful with that... if you're going to have the same set of buttons on multiple cards, then a background group might make sense. Perhaps the whole app can use just one card and the buttons display various groups (I usually do that).

[chelling]

It's for children with low vision, speech and physical disabilities. The buttons represent vocabulary words that when clicked, takes the child to an animation of the vocabulary word across the screen.

[Randy Hengst]

You could send the user to anther card to show then animation and return to the button card when the animation finishes. Or, the animation could be in a group that is shown on the same card as the buttons. I'd try setting up three or four of the animations in separate cards and in groups to compare ease of development and use. You could set things up where all the animations are on one card, or one animation per card.

I made an alphabet app that used one card per letter, but virtually all of my other apps use one "game card" with groups hiding/showing as needed. My apps are for elementary school-aged children and aren't very complicated.

[chelling]

Thanks Randy. I appreciate your help.