. @Simeon I don’t know if this was brought up or not, but I ran into a keyboard problem. Run this program and tap the “show keyboard” button. The keyboard shows and the “isKeyboardShowing” shows true. Press the “hide keyboard” button and the keyboard is hidden and the “isKeyboardShowing” shows false. So far so good. In the Parameters window, tap the “input” window and the keyboard shows, but the " isKeyboardShowing" shows false and pressing the “hide keyboard” button doesn’t hide the keyboard. If you press the “show keyboard” button, nothing happens to the keyboard, but the “isKeyboardShowing” is now true and pressing the “hide keyboard” button now hides the keyboard. It looks like when the keyboard is brought up because of an input request, the state of the keyboard isn’t updated.
function setup()
rectMode(CENTER)
parameter.text("input")
end
function draw()
background(40, 40, 50)
if isKeyboardShowing() then
kb="true"
else
kb="false"
end
fill(255)
text("isKeyboardShowing "..kb,200,500)
rect(200,800,200,50)
rect(200,700,200,50)
fill(255,0,0)
text("show keyboard",200,800)
text("hide keyboard",200,700)
end
function touched(t)
if t.x>100 and t.x<300 and t.y>775 and t.y<825 then
showKeyboard()
end
if t.x>100 and t.x<300 and t.y>675 and t.y<725 then
hideKeyboard()
end
end
.@dave1707 I wouldn’t say this is an error, it’s hard-to-define behaviour.
Codea’s showKeyboard and hideKeyboard methods are showing a keyboard that can input text into Codea (via the keyboard(key) function, for example). So isKeyboardShowing() is telling you the state of the Codea viewer’s keyboard, and not the sidebar’s keyboard.
hideKeyboard() is telling the Codea viewer to hide its keyboard — it is not controlling the sidebar input field behaviour.
I can see how this is confusing, but I’m hesitant to have these function also influence the sidebar’s behaviour — the sidebar is intended to be under the power of the person interacting with the viewer.
The way I get around it is to do a showKeyboard() just before I do a hideKeyboard(). Of course the isKeyboardShowing() isn’t helping me, I just know I need to hide the keyboard at that point.
.@dave1707 What I normally do is I would set a variable equal to isKeyboardshowing()
lets call that variable visible.
visible = isKeyboardshowing()
and usually I would place that variable declaration in my draw loop so its persistent.
isKeyboardshowing() will give you true or false naturally.
So then you insert a conditional statement in your touch function to check that variable.
function touched(touch)
if visible == true then
hideKeyboard()
else
showKeyboard()
end
end
Of course you could further limit when it should show up or disappear by adding that to your touch conditons.
function touched(t)
if t.x>100 and t.x<300 and t.y>775 and t.y<825 and visible == false then
showKeyboard()
end
if t.x>100 and t.x<300 and t.y>675 and t.y<725 and visible == true then
hideKeyboard()
end
end
Would you prefer if the behaviour hideKeyboard() hides keyboards shown from any source? As I said above, if isKeyboardShowing() is true, it means that the visible keyboard can interact with the viewer through the keyboard(key) callback.
I would like to start some discussion on the best implementation of the API now that keyboards can be triggered for external text fields.
. @Simeon I think that if the keyboard is showing then isKeyboardShowing() should return true. It should be up to the person writing the code to make the decision on what to do with the keyboard. I just woke up so I haven’t thought this through all the different situations yet if there would be a problem.
.@dave1707 the only potential issue I can see is with something like the iCade controller (it acts as a bluetooth keyboard). You would use isKeyboardShowing() to tell if it’s connected and pointing its input towards the viewer (and not the REPL or a parameter.text field).
.@Simeon I’m looking at it from an iPad user only, without an external keyboard. I’m not familiar with the situations that the other users may have, so I can’t really say what the best way is. Like I said earlier, if I want to hide the keyboard, I just do a showKeyboard() before a hideKeyboard(). If the keyboard is already hidden when I do that, the keyboard pops up for a fraction of a second before it disappears again. That works for me so far.
My initial inclination is that the isKeyboardShowing should be restricted to the keyboard as displayed “in program,” not a keyboard called up from what’s essentially the debugging environment on the sidebar.
Why? Because it just seems like a cleaner implementation. I can’t imagine developing a lot of code that depends on this function, since code developed using activity from the sidebar can’t run outside the development environment (i.e. popping the keyboard from the sidebar seems like something that you do while testing out a bit of code, not something you’d use as a feature of a complete program).
On the other hand, most functions in Codea do seem to be aware of activity on the sidebar. It’s not just that parameters can be passed in, values like WIDTH return differently when the sidebar is open. And not every program is developed to run outside of Codea’s warm embrace. And… I honestly can’t see what it would hurt.
Could there be multiple isKeyboardShowing() functions. One for if the devices keyboard is showing and another for an external keyboard connected ( isExtKeyboardShowing() ). I’m not sure how the other devices work with Codea, so I don’t know the situations for the different keyboards.