Hi so I have ti nspire problem. Code:
Code: local x=0
local y=0
function on.arrowUp()
y=y-10
end
function on.arrowDown()
y=y+10
end
function on.arrowLeft()
x=x-10
end
function on.arrowRight()
x=x+10
end
function on.paint(gc)
gc:drawString("O",x,y,"top")
end
I script on an editor called Jens' Script Editor (using version 2.2.1). It is an on-calc editor. I am on a clickpad nSpire with CAS OS 3.6 installed, but these problems happen on non CAS and other versions as well.
Basically, the above code, if I use the student software, which has a built in calculator emulator (running version 3.9 but other versions are the same), and am running JSE 2.2.1 on the emulator, the code above will run just fine. The screen refreshes and the "O" will move around the screen.
When running JSE 2.2.1 on-calc, the above code will not update the screen at all, the "O" will stay in place on both OS 3.6 and 3.9. If I add:
"platform.window:invalidate()"
At the end of each on.arrow function, then the screen will update properly. However, on OS 3.9, the screen will refresh after adding the above invalidate command, but it won't erase the old "O". It will only create a string of "O"s along the path you draw.
But on 3.6, adding the invalidate command will cause it to refresh complete correctly, and the "O" will move around without leaving a trail.
Is there anyway to fix the on-calc issue? Or anybody might have an idea why it's even happening? It is the exact same script editor, the only difference is that one instance is on-calc, and the other is the same exact calculator with the same OS version, only difference being that it is emulated.
So why would the emulator refresh correctly and the on-calc wouldn't?
Please and thanks!
Note that the computer software is *not* an emulator, but it's the code that is natively compiled, and an interface that has an option to make it look like the calculator fyi can also make it not do that and enjoy a "full screen" experience, i.e. not limited to 320x240. It's also why you're encouraged to never use hardcoded sizes/coordinates when writing Lua scripts: the desktop and tablet versions won't be running 320x240...
Anyway, this trail of O is weird - but I'm not sure I understood correctly - does it only happen within JSE? Or within a normal Lua script directly saved in a tns from ti's software (or Luna), i.e not in JSE ?
Adriweb wrote:
Note that the computer software is *not* an emulator, but it's the code that is natively compiled, and an interface that has an option to make it look like the calculator fyi can also make it not do that and enjoy a "full screen" experience, i.e. not limited to 320x240. It's also why you're encouraged to never use hardcoded sizes/coordinates when writing Lua scripts: the desktop and tablet versions won't be running 320x240...
Yeah, I'm aware of the whole screen and stuff, but my goal is to learn to script entirely on-calc using JSE. That's why using the computer software, I still run JSE and script in it, despite it having it's own script editor already. I'm just using it as a more convenient way to type, which then lead to me encountering this issue. And I'm fine with using exact coords rather than relative ones bc I'm really only trying to program for the calculator I'm using. This is more just for me, rather than developing anything for other people.
Quote:
Anyway, this trail of O is weird - but I'm not sure I understood correctly - does it only happen within JSE? Or within a normal Lua script directly saved in a tns from ti's software (or Luna), i.e not in JSE ?
I just tested by recreating the code using the ti software and saving the script to a tns. When I run that same script in the software, it will run like normal. But if I transfer it to the handheld and run it there, the "O"s position will not update. Once again, I have to add "platform.window:invalidate()" to each arrow function, and only then will it update.
I should mention I've resigned myself to using OS 3.6 because at least in this case, when I use invalidate, the screen gets wiped each invalidate and the "O"s position will update and only the newest "O" is drawn.
But yeah, this issue is only on the handheld, using either JSE or a tns made from the software. If it's run in the software, the screen refreshes by itself, no need to use the invalidate command.
Edit: Forgot to mention that the issue with it not wiping the screen and only displaying the newest "O" is only present on OS version 3.9.
The problem with the screen not refreshing in the first place unless an invalidate is placed in the arrow functions is present in all OS versions. So the trail issue where all the old "O"s aren't wiped is only an issue on 3.9, which I've stopped using for now.
I just want to know if I can make it where I don't need to add the invalidate command at every function in order to refresh the screen, since it's supposed to do it automatically with on.paint.
It may be a bug in the 3.9 OS then, although very surprising. Honestly I haven't dealt with pre-CX calcs in more than a decade...
Regarding the "invalidate" bug that's definitely not a bug, it's the expected behavior! The OS will do as little as needed, in order to save computation (and redraw) time. That means it won't consider the screen to need a redraw unless you told it to (how could it know anyway, you just changed some variable in the arrow handler), which is why you have to tell it explicitly that the window has been invalidated.
Adriweb wrote:
It may be a bug in the 3.9 OS then, although very surprising. Honestly I haven't dealt with pre-CX calcs in more than a decade...
Definitely an odd one. If only I could just install CX OSes on my clickpad but I already tried and it just bricks it and I have to redo my nlaunch install...
Quote:
Regarding the "invalidate" bug that's definitely not a bug, it's the expected behavior! The OS will do as little as needed, in order to save computation (and redraw) time. That means it won't consider the screen to need a redraw unless you told it to (how could it know anyway, you just changed some variable in the arrow handler), which is why you have to tell it explicitly that the window has been invalidated.
Is there any way to change this? Either make the calculator consider the screen always, or make the student software work the same as the calculator?
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
