So um... I kinda fixed the issue with the first and second inputs swapping? I realised that I was being dumb this whole time, I had to completely rework the code. Fortunately, Find...Replace is a thing. What I replaced: currentIndex-1) >>> currentIndex-2) currentIndex) >>> currentIndex-1) currentIndex + 1) >>> currentIndex) So now that problem is solved... not really. It's just made it so that now index = 0 is unreachable, rather than the last index being unreachable. The reason I made this change is because I noticed that I was able to do "++++:+54367etc." when + should have been invalid. I then noticed that + was invalid here; "5436:5+". That's when it hit me. (Sidenote: at least the user can press delete and clear. Only issue is that those buttons aren't there. The user must use keybinds instead; shift+c, backspace) Also, I've noticed that the larger buttons seem to have null images for image1 (or at least it seems that way because they disappear) and the smaller buttons don't change when invalid. Which is strange, because the larger buttons definitely have an image1, and the other buttons definitely should be changing image. Edit: I must have accidentally ctrl+z'd or deleted those lines of code at some point... Fixed now.

FINALLY! I've discovered what the issue was with the regex; it was replacing the regex expression just fine, but the outputted string wasn't assigned to a variable, which is why System.out.println(string.replaceAll(regex, repl)) worked but the string itself was unchanged. That explains a lot. Also, it seems (though I could be wrong) that when the string is transferred to another method, it loses the replacement? I'm not entirely sure, but for the most part, equals no longer throws an error. Instead, it creates an infinite loop that takes up 100% CPU... great. I think it's still looping even though I've stopped running it. Very jittery. Not sure why this loop is occurring... wait. I bet its for the same reason the regex wasn't working. I'll update this when I'm able to edit my code again (can't right now due to 100% cpu) Edit: still at 100% cpu, execution refusing to terminate... Edit 2: I think it worked? But now it throws a different error, I think it's because I unintentionally named all the filereader/filewriter variables for each static class have the same name. Just updated the scenario. Really should get working on documentation.

Ok so now most of my problems on the main part of the software are solved, problem is that I'm getting this error (repeated): java.lang.NullPointerException at Calculations.writeCalcHistory(Calculations.java:111) at Calculate.addCalcHis(Calculate.java:304) at Calculate.beginCalculation(Calculate.java:297) at Calculate.add(Calculate.java:117) at Button.buttonPress(Button.java:209) at Button.processButtonPress(Button.java:183) at Button.checkKeyPress(Button.java:177) at Calculator.keyPress(Calculator.java:446) at Calculator.keys(Calculator.java:357) at Calculator.act(Calculator.java:313) NullPointer when writing to calchistory file. How do I fix this? I've changed variable names but that didn't work. What's causing this? Edit: solved my own problem.

This line really needs to be removed. Just validate the buttons, but not by calling add. With all the changes given in my last post, cursor control would be completely fixed. So, yeah, it would then just be a matter of button validation.

I tested what would happen if I removed that line and had no noticeable difference, other than all buttons being valid, which could end up with an error (I mean, I guess it's the user's fault if that's the case?). May I ask what you're getting at with the removal of that line?

Also, is there a way to convert Greenfoot to a .exe? That's fine if not, but I think my teacher spoke of something like the conversion process or program or whatever being non-functional at this current point in time? I'm also a little concerned that I have not finished Store, Alpha, displays for other worlds, etc, but there's not much I can do without it taking too much time.

If I remember correctly, every time add is invoked, the currentIndex field is explicitly incremented.

Yes. First make an executable jar file ('Share' >> Application tab). Then use a program like Launch4J to convert jar to exe.

Sorry for late reply. Yes, that is the case, except this is cancelled out.

I'm not sure how to use launch4j. I'm looking at it now and I don't understand what is happening. Might be the sleep deprivation talking. I've got my program in a zip file, but it requires an exe file to be selected in order to create an exe file? I'm confused. I've looked up a tutorial but the guy just doesn't appeal to my short attention span (extra short cus fatigue) and there are no launch4j tutorials that relate directly to greenfoot. I really appreciate your help so far, you are a lifesaver. I do need to know how to do this though, as I need to create an installation guide. I don't know if launch4j will factor into the installation guide because I've never used it before.

They will not be specific to greenfoot. They will be specific to (executable java) jar files. You can create an executable jar file from greenfoot, then (without greenfoot) use Launch4J to convert the jar file to an exe file.

It's not working. I think my teacher knew about this and just said to pretend that it does... 101 RCDATA BEGIN "An error occurred while starting the application.\0" END 102 RCDATA BEGIN "This application was configured to use a bundled Java Runtime Environment but the runtime is missing or corrupted.\0" END 103 RCDATA BEGIN "This application requires a Java Runtime Environment\0" END Though I've never used this before so I'm likely wrong.

I must admit, I have not either. But it sounds like you probably had a setting off in Launch4J.

I do not think there will be any real issues other than maybe trying to run a 64-bit coded program on a 32-bit or smaller system.