@Simeon math.hugh works with parameter.number. The status bar doesn’t show at the top of the editor screen. I don’t use Air Code, so I can’t say anything about that. Not sure what the other compatabilities are that need to be looked at.
liked iOS status bar–would like it everywhere but in running code and even an option for it there.
in editor would like iOS status bar with tab height shortened so names fill vertical space used and below status bar.
I like to see status bar to tell when battery is low or to see time, wifi dropped, etc.
Air Code works as expected.
Thanks everyone for the quick testing.
@CodingOnNapkins unsure on whether to include the status bar as an optional thing. Will think about it.
how about showStatusBar() as a function to put into draw() only when we want it?
how about showStatusBar() as a function to put into draw() only when we want it?
I agree, this could be a function called out of setup like displayMode or supportedOrientations. It could also be used instead of the setting while exporting.
@Simeon, now Codea 2.3.1(46), appears on my Test Flight on iPhone to install, but when I try to do it, it can’t be installed.
Any ideas?
@Simeon, another thing, when I swype down/up or close the Codea’s forum, the sccreen moves like when we use displayMode() and ‘hide’ the parameters bar
@erickyamato don’t try to install it on iPhone. It’s not built for iPhone and shouldn’t show up there. I’m not sure why it is showing on your phone.
I just found a glitch. When you press a normal key and the a key on the extra row of buttons, sometimes the touch doesn’t register.
Thanks @Saturn031000 — though I am unsure if we can address that (it could be the Apple keyboard is just not letting us know of the touch event).
The next build (47) is likely the App Store version of 2.3.1. I have significantly changed some of the viewer layout and startup sequence code in order to fix the distortion issue in exported project. Please let me know if any of your existing code behaves differently with regards to displayMode or orientation support.
@Simeon Loaded latest beta. Haven’t run into any problems with displayMode() with any option in or out of setup(). No issues with orientationChanged().
@Simeon I noticed a difference with the code below when starting in different orientations. Since I’m not setting displayMode anywhere, it appears that the WIDTH and HEIGHT are being set before you determine what the default display mode is.
print("outside",WIDTH,HEIGHT)
function setup()
print("in setup",WIDTH,HEIGHT)
end
@dave1707 thank you for your quick feedback. I believe the behaviour in your last example hasn’t changed. The correct width and height can only be known once the app has started drawing (so when setup is called).
@Simeon There’s only a few statements that I set outside of setup, so I wasn’t sure if that was a problem or not.
Got the latest update from testflight today - one thing I did notice is (in landscape mode) there is a nasty glitch when entering exiting a project and also when bringing up the reference / aircode sidebar. It looks like screen fractures roughly around where the in-app side panel appears and then resets just before the transition takes place - this is happening in both the last two testflight updates.
@TechDojo I’m on an iPad Air and the transition of starting or exiting a project is very smooth. The project name image rotates 180 degrees to and from the editor. Is that what you’re referring to. Also, bringing up the reference / air code sidebar is smooth.
got “error:attempt to compare nil with number”
with no source info about where it happened?
any chance of a quick fix?
other wise 47 ok.
@CodingOnNapkins that sounds like it might be a logic error in your code. Are you able to share the code so I can test?
@dave1707 - I’m running on a 64gb iPad 3, with iOS 8.3. I have at least 100 projects and I can also see the glitches when I scroll the project list to the bottom particularly when I scroll past the examples.