Better handle manually-entered paths

[NoahAndrews]

For a visual cue, maybe the text box should have a red border, and once the app detects a) a valid filename and b) that the file exists, turn the box green. I don't think a simple test for a string ending in .hex should slow things down noticeably even if we test with every keystroke, and if the filename is valid, the user is probably done typing, so the second test shouldn't be a problem either.

Once the file checks out, call loadHex().

[skullydazed]

I've been thinking about this one. Part of me wants to make that a read-only box, because it would confuse non-technical users if they accidentally edited a previously working file. Perhaps this is a good candidate to put into the Advanced tab, after that is implemented?

[NoahAndrews]

I mean, the open dialog already has an option to type it in manually. We could get rid of it altogether, I suppose. I don't understand your reasoning about accidentally editing a previously working file though.

[skullydazed]

The scenario looks something like this:

• User drops a file in or selects one through the file picker
• User accidentally clicks and/or drags in the file box, maybe without realizing it (think trackpad on a laptop)
• Keys are pressed, and now the filename is invalid

If that's read-only the chances of that happening are 0, but we can still allow power users to access that functionality in the Advanced tab. Or, like you say, we can remove it entirely and leave it for the file picker.

[NoahAndrews]

Ah, gotcha. Yeah, let's make it read-only on the basic tab and writable on the advanced tab. I think I'd rather not get rid of it entirely, since we aren't ever loading the file into memory, and if the file were deleted or modified, flashing would fail / the modified version would be flashed. I think showing the path we're going to load the file from better conveys how that works.