vinnydiehl / nds_toolkit Goto Github PK

As of now, the inputs in the application require the code to be in the following column format:

XXXXXXXX XXXXXXXX
YYYYYYYY YYYYYYYY

Aside from trimming any whitespace on the left/right sides of each line, there is no further enforcement of this formatting; depending on the severity of the user's poor formatting, the output could either be weird or completely broken.

I'll be creating an issue branch for the addition of a class containing static methods that:

• Verify that the input is indeed NDS code.
• Format code into a proper 2-column format.

The addition of this class will also open up an opportunity for a new tab: a code beautifier. That will be up for discussion on a later date.

I am working on a widget that is designed for making the entry of a line of AR code very easy. It almost works, but currently has one debilitating bug that is stopping it from being stable- Upon entering the 9th character, it auto-inserts the space, but leaves the cursor sitting before the 9th character. This is deceptively hard to fix.

To implement the new functionality of downloading the latest usrcheat.dat, a new frame that downloads the file must be implemented.

What still needs to be considered is how the file selection must be presented; should the file dialog-

• be shown when the frame is constructed
• be a method of the frame, or
• be shown prior to the creation of the frame and have the download path passed into the constructor?

I'm leaning heavily towards the second option.

The Button Activator Generator page of the .NET tool has advanced way past this version's. The user interface must be completely redesigned, and the controller class will need some additions to handle code input. This will be done in a seperate branch, to avoid breaking the page in inbound/central.

A normal textbox seems kind of crude for the purpose of listing strings, and a listbox is in fact perfect for this task- using a listbox to display the pointer search results will also allow for the implementation of future features involving the search results, as right now it's only a display.

The NDS Toolkit has an excellent beautifier that works behind the scenes to make even the nastiest code parse-able by the various algorithms that the tools employ, but the user has no direct front-end to this beautifier. I've waited until the rest of the project was pretty stable before spending time implementing this, and now, I feel, is the time to begin.

Before being merged into inbound, the page should probably be deactivated by default, and not added to the default build setup until it hits the trunk at least. This gives the .NET tool a chance to catch up, something that I will help with once this issue is resolved.