PinkPuff, I'd suggest padding out character names out to six characters with blank spaces. It'll make the text preview a bit ugly, but it'll stop people from writing dialogue that gets cut off when someone renames a character to have a longer name.
Both have their advantages. What about if it were to look normal when you preview it from the main dialogue select menu, but padded while typing?
Everything is looking solid. I only have one suggestion and I'm not sure how difficult it would be to implement. Is it possible to have the message be edited from the very NPC option? I noticed you added the Sprite and NPC identifier in which makes identification unnecessary and in the process makes things so much easier to read.
Like say for Mist, there are a lot of Bank 2 message references. Granted all one would need to do is keep a mental record of which line it corresponds to and move on from there, but to cut down on time and accessibility, being able to edit it from there would help things move along at a steadier pace.
I thought of this during design but while it's technically possible to do I decided against it due to the potential awkwardness.
To illustrate, the Mist example you used, where the NPCs are not actually speaking messages in their parameter list, but just using those "show message x from bank 2" event calls, you may notice I don't even have a preview of the text there for those. The reason is that, with the message parameters, you know they're always messages, and you know what map they're from (since you know what map the NPC is from). With the event calls like the ones in Mist, at first you might be tempted to think, "well we know this block of events are all just a single line of 'show message x from bank 2' and we know what map the NPC is from, so we can just have any NPC with a trigger that calls one of those events to show it" but there are a couple of problems.
First, suppose you have an NPC's speech set up as follows:
* If Flag 1 on, call event "show message 1 from bank 2"
* If Flag 2 on, call event "show message 2 from bank 2"
* -- always --, call event "show message 3 from bank 2"
How would one expect a preview of all of those to look? At first you might say "well just have it preview one when you cursor over it in the event select component of the menu", but then the problem arises that nothing is stopping the user from going into the actual event editor and changing the event that used to simply consist of a single line "show message x from bank 2" into an entire plot scene, or something completely different altogether. Even though the game
defaults to having that section of events devoted to simple bank 2 calls, nothing is forcing it to be that way, especially after using this editor.
So maybe we can just have it search each event when you highlight it for bank 2 references? This is possible but would likely be more time consuming at run-time than it's worth. Plus, what if one event has a whole bunch of bank 2 references? Do we preview all of them? If not, which? The first one?
So I think it's probably ok the way it is. I know it may be a bit of a pain to go back and forth between editors, but if you're doing small changes, then it should be easy to put up with, and if you're doing a large project then chances are you probably have your planned NPCs and dialogues and such already written out in another form anyway (or if not then it's a good idea to do, regardless).
But that's merely for later. I think for now you have nearly all text matters done (only thing missing are location names). As for Location Data there is still the Map Data (which JCE3000GT's Map Variables Editor can change) and that should be it as far as maps and events are concerned. I am curious to know what direction you plan from there? You've made a great tool so far and I am looking forward to the future of it!
Thanks! Glad to hear people are enjoying it and finding it useful. Positive feedback always helps motivate me to keep working on it!

Yup, map properties are probably next, and actually I had planned to include the map names with that component (rather than with the dialogues and messages/alerts).
As far as maps and events are concerned there actually
are a couple more things on the table. One is obviously overworld triggers. I had a look at the info here:
http://slickproductions.org/forum/index.php?topic=1769.0 This might be the thread you were looking for PinkPuff in regards to World Map Triggers.
... but as far as I can tell it will probably only be able to edit/create teleporters, not actual event calls. Unless the event call data for the overworld/underground is known and I missed it? Yup, I did *facepalm*. Yeah it shouldn't be any trouble.
Anyway, I would like to at some point also include editing the actual maps themselves, such as FF4Tools is capable of. The differences being that it would actually have a rom to edit rather than manually copying and pasting large chunks of hex code and pointers into the (hopefully) correct spots, it would be able to make maps larger than they were in the original (provided that other maps are made smaller or that there is room, but the point is that it would be able to look at the entire space set aside for maps rather than just the one you're editing), and it would (hopefully) be able to read the tile graphics from the rom you're editing in much the same way as it does with the font and window graphics so that if you change a tile or create your own custom tiles (or heck, why not an entire custom tileset) they will look correct in the editor instead of always using the default graphic tiles.
Try not to get too excited about that though, I'm a
long way, and a
lot of research away from being able to accomplish that; but I do know the basic gist of how to go about it, it's just a question of the details and how much of the relevant info is documented or I am otherwise able to be decipher.
More than likely, the next "group" of editors after the map/event group will be monsters. I know there's a lot of data documented about those and I think I can make editors for those fairly straightforwardly.