I meant the play button. It worked in the previous build (i use it all the time)
edito bug.
put that in the editor:
TitleButton.rectStyle1 = {fill=color(0,0,0,0), radius=4, strokeWidth=2, stroke = color(0,0) }
TitleButton.rectStyle2 = {fill=color(0,0,0,0), radius=4, strokeWidth=2, stroke = color(128,128) }
do you see the last “}” when the color circle shows? No. Not very good for inspecting for errors…
@Ignatz I’d very much like to break the API and go with @Jmv38’s original suggestion for only having the callbacks after initialisation. Still weighing the options. I might try it out next build so people can see what it’s actually like.
@Jmv38 does the play button not work under specific circumstances, or when there is specific code? Was 2.1 (7) OK?
The colour circles should disappear when you are editing that line (the intention is that you need to see everything on the line you are editing, so they disappear).
(These are old issues, but still there.)
When pressing search then the top row of buttons disappears and I think it would be useful for it to stay.
When in the documentation browser starting from a lookup on a selection then it takes two presses of the eye to dismiss it.
Just tried the text editor.
- It didn’t save!
- Any chance of a spell-checker?
play button: 1/ [edit] sometimes doesnt works for me (i have to use the one without keyboard) i dont know the circumstances and 2/ it was ok before current build.
color circles: yes, i know what you say. But when you inspect code you dont want to be tapping every line to check for the hidden char… However i can live with it.
@Andrew_Stacey odd! It has auto-save enabled, I’ll look into it. I’ll be adding autocomplete to the text editor, unsure on spellchecking.
@Jmv38 very strange, I can’t reproduce the play button issue. I’ll keep trying.
play button: doesnt occur any more now…??? I’ll save the code the next time it appears.
Concerning the color dot: maybe you could put it inside the parenthesis of color(,) instead of outside?
Not sure why, my game froze on one frame:
https://www.dropbox.com/s/ejbcu52gg535d3e/Photo%2022-08-2014%2014%2040%2006.png
Stayed like that being unable to press buttons then went to this and was unresponsive:
https://www.dropbox.com/s/ugmod2f615c9shr/Photo%2022-08-2014%2014%2040%2015.png
The font size does not reflect Codea’s settings. Look at this two screenshots, code editor and shader lab reflect the 18pt but not the text-editor : https://www.dropbox.com/s/sdw1p1vbr39op1b/Photo%2022-08-2014%2019%2018%2054.png and https://www.dropbox.com/s/4ev2xxrvqdxphxz/Photo%2022-08-2014%2019%2019%2054.png
@toffer thank you — I didn’t realise you meant the plain text editor. Thanks for finding that, will fix.
@Luatee have you been able to re-create the issue?
@Simeon, I think Luatees issue comes when you have an error in your code. Will try to make a small project that causes it.
@JakAttak there is no error, it’s exactly the same as when I backed it up, it ran with no problems.
@Luatee, hmm. Must be a different issue then, sorry.
####Bug:
with supportedOrientations.
1/ in my project i have supportedOrientations(LANSDCAPE).
2/ from this project i loadstring( project2 )().
3/ project2 contains supportedOrientations(PORTRAIT).
4/ but project2 still runs in LANDSCAPE.
Is this the expected behavior? It feels like a bug for me.
@Jmv38 this is not something we can elegantly solve.
If you use supportedOrientations in your global scope (i.e., outside of setup() and draw()) then Codea knows which orientations are supported just before the viewer is presented. This allows the viewer to be presented in the desired orientation (e.g., Cargo-Bot does this)
However once your project is running and the viewer is up, Codea is not able to “force” the viewer to rotate to a new orientation. It will rotate (and stick) once the user orients their device, but we can’t force it.
@Andrew_Stacey I am so far unable to re-produce the not saving problem. Was it a very large file?
Also in my testing ellipseMode appears to default to CENTER.
I am also unable to get the documentation viewer to “stick” by using the Lookup feature on an API call. Will keep playing with this.
@Simeon
It was about a page of text. I then tried with single lines and it still didn’t save. However, I tried again yesterday and it did save. Maybe it was when the file was first created? I’ll try some experiments.
I’ll test again with ellipseMode. Something weird happened in that all my ellipses suddenly doubled in size going from one version of Beta to the next. I thought I’d narrowed it down to a change in the default ellipseMode, but maybe I’d made some other change elsewhere.
The documentation stickiness appears to have been fixed. I thought it was happening with the latest version but I agree that it isn’t now.
Ooops! Looks like none of my reported issues were still current!
Oh, apart from the extra keys in search. That one is still there.
@Simeon I could not recreate the issue, I tried to. I think it’s related to the errors I’m getting as I’ve been able to isolate the problem.
@Simeon I haven’t had the time to load the new Beta code and test it, but I ran across this in the current code. Its probably in the Beta code also. This is about the boolean parameter switch. It switches when you tap it, but if you touch the switch area and drag your finger around, it constantly switches. It should change when touched, but not change when dragging.
function setup()
count=0
parameter.boolean("MySwitch", true, switchChanged)
end
function switchChanged( value )
count=count+1
print( "MySwitch changed to " .. tostring(value).." "..count )
end