Version 3.0.0 Release

Here it is, the latest version of HexaEdit CE!



When you first download this program, please read the README. HexaEdit is designed for power users, so it does not come with training wheels. You can seriously mess up your calculator with a few simple keystrokes.


-------------------------------------------------------------------------------------


It's been quite a journey since the first release three years ago.

Version 1



Version 2



Version 3





-------------------------------------------------------------------------------------


This will be the last major revision of HexaEdit CE for a while. I am ready to finally shelve its active development and pursue other programs for the CE and other platforms. Nevertheless, it has been a blast, and I am indebted to all of the community support here at Cemetech to get this program off the ground. Thanks a lot!


-------------------------------------------------------------------------------------




That's pretty much it. I have included a large section of documentation and example code in the README to explain how it works. I did scrap the call from TI-BASIC idea to reduce the program's complexity and get a release out sooner.

Enjoy!

I've had a bit of time to test this out now and offer some feedback. I think that overall the program is an improvement over the previous versions and does its job very well, but there are some notable areas where I felt that things were made more unclear or don't work as well as they used to.

- The main menu: I really don't like the new design of this. It took me a few minutes to realize that the gray bar at the bottom of the screen was used to indicate what section of the menu I was in. I liked the original's design, where it grayed out the other regions, much better. I also liked the single-pixel borders around things in versions 1 and 2, and 1's larger spacing between menu items. This new menu looks far too cramped and basic for my taste. Here's a mockup of what I would prefer, mixing the styles of 1 and 2 with the new menu layout:

- Input: The input needs some debouncing--there were a good amount of places where double activations made it difficult to use the program. A few of these were the main menu--where sometimes pressing the directional keypad quickly would lead to the selection box jumping multiple places downward or side to side, and the cut/copy/paste dialog, where pressing [clear] usually returned me to the main menu instead of cancelling the action. In cases where you can hold a key--like on the main menu--there should be a small delay before it starts doing so that resets every time the key in question is released.
- Editor: I'm mostly pretty satisfied with this, but the one large issue I have is the lack of clarity in the "i : x : 0 : 1" message or similar. Reading the readme did tell me what everything means here, but the format still was difficult to remember even after doing so. I think that the first one--which tells you whether the variable can be overwritten/read/inserted into is pretty much useless considering that you're already graying out options (maybe there could be a message that pops up when you open the editor that tells you if the variable can't be written to or something). The second, the current input state, would ideally be in a black box with white text next to the battery indicator like in TI-OS. Then you're only left with the selection size and clipboard size, which users should be able to figure out. Also, [alpha] should really change the input mode.
- Clipboard: I don't have any huge complaints with this, but I do think that it would be worth considering having the default behavior being inserting the contents of the clipboard at the cursor location instead of overwriting. Then, if you can't insert bytes, you can just overwrite them (maybe give some indication that that's what will happen as well). Inserting the desired number of bytes, selecting all of them, and then pasting the clipboard contents (assuming it matches the size of the selection) is a lot more work than just selecting, copying, and pasting like every other program.
- Battery icon: Bring it back please... (see my mockup above, version 1's was the best)

Anyway, good work on this! As always, this is a very helpful program that I use quite frequently--I wouldn't offer feedback otherwise.

Is there a way to uninstall this fully because I broke it (somehow) reinstalled it and it still was broken. I tried it with an emulator and it worked though. It says "Warning: Cannot save Recents appvar" and whenever I save things, instead of saving my edits, it basically breaks the file with random values but with the same amount of bytes. It views files correctly but breaks when I try to edit it.

The error you got usually occurs when you have too many programs/files in memory. HexaEdit requires a great deal of RAM to operate, so if it cannot get as much as it needs, it will still run but it will not save the most recently edited files. If you delete HexaEdit or clear your calculator's RAM while HexaEdit is in RAM, it will be "uninstalled."

Your problems might be related to a bug I found in the Find function recently. I will investigate.

Thank you epsilon5 for all of your feedback! I really appreciate it. Unfortunately, I decided to cut the "insert clipboard bytes" feature early on in development because it would create too many complications. The underlying buffer code was designed without it, and attempting to retrofit the feature now might invalidate the logic of a large portion of the core codebase. I designed HexaEdit 3 for stability, which requires a slow, methodical approach to feature implementation. However, if I have misjudged the effects of adding the function, I might reconsider it.

I am planning on doing some work on the debouncing issues you described and making a few minor tweaks to the UI.

I've been giving HexaEdit 3 a try and it's way faster! It's definitely a lot easier to use than the older version, so great job on that. I will say that I agree with the key press issues though.

Do you display an error message if there isn't enough RAM for HexaEdit to save edits? I feel like there should at least be some sort of warning message if there isn't already, the way that it warns you about being unable to save the AppVar. I'm not sure if this already exists or not though, since I've never encountered the issue myself.

As far as the key debouncing goes, I'd suggest using some sort of clock() timer where it will wait slightly longer after the first key press to continue repeating the key press (If that makes any sense). That way you can still hold down keys, and it gives a similar behavior to holding down a key while typing on a normal keyboard. Sorry if I didn't do a very good job explaining it, I can upload an example gist a bit later when I'm able to if you're interested.

Overall, nice work, it's definitely a big improvement from the last version!

Edit:
You can find the example gist here.

Thanks for the feedback and the gist, TInyHacker! I have been doing a little experimentation with key delays, and it might be possible to integrate the delayed-keypress-follow-up you described in your post.

I have seen several references to the "Warning: Cannot save variables to Recents appvar" error, so I want to explain how it can occur. When HexaEdit starts for the first time, it creates an appvar to store up to 15 of the variables that the user has edited. The program sizes the appvar to 255 bytes, more than enough memory to hold all of the variable names. The program allocates all of the memory for the appvar at once so it does not need to resize the appvar. Version 3 tries to avoid dynamic memory allocation as much as possible.

Every time HexaEdit starts, it creates another appvar, the edit buffer. In version 2, I ran into problems when resizing variables in the editor: pointers to data within the variable would be invalidated every time the variable's size changed. Therefore, in version 3, HexaEdit tries to make the edit buffer as large as the largest variable the user could ever have, consuming up to nearly 64KB at maximum. If it cannot grow to the maximum, the appvar will consume all the free RAM it can. This approach is essentially treating the appvar as a static memory allocation, ensuring that none of the pointers to it will be invalidated as long as no file operations happen after the edit buffer has been allocated.

Now, if HexaEdit cannot allocate an edit buffer of maximum size, it will not attempt to save the most recently edited variable. The saving process requires opening the save appvar, HXEDITr, in "r+" mode. This line ensures that there is some spare RAM available before the program attempts to save a variable name. Looking at the code in retrospect, I am not sure if the safeguard is necessary. I have a suspicion it is there because FileIOC would act up if all of the free RAM was in use, but if not, it might be removable.

In a nutshell, you should not get the error if the free RAM amount in HexaEdit's main menu is at least 300 or so.