wxFRED2 WIP builds (Windows)
wxFRED2d_13-3-10.exe - Debug build, requires MSVC debug libraries
wxFRED2r_13-3-26.exe - Release build
wxFRED2 patch file (vs. r9565)
wxFRED2d_13-3-23.patch (Scroll down for pic's)
Well, it's been about 2 months since I started on the wxFRED project, and I thought it might be a good idea to say something about it.
First off, some good news: I've managed to get most of the editors (down to Mission Specs Editor, starting from the top of the Editors menu list) graphics implemented. Bad news? well...
Today, I did an OS theme switch to test whether or not wxFRED would match the color theme of the OS (it does by default). However, when I was doing this I had wxFormBuilder still open. There was no indication that anything was wrong until I tried to save my changes, at which point it decided to crash.
No big deal, right? Kinda is. wxFormBuilder crashed
while it was doing the save, thereby nuking the project file completely and trashing whatever saves I had made, along with all progress I had made up until that point. Clumsy me, thinking that such a thing would never happen, did not think it was pertinent to make backups, so I'm basically back to where I started as far as the project file goes...
The silver lining, however, is that I still have a copy of the C++ code that was generated by wxFormBuilder, and I can still compile it in MSVC and get wxFRED to run and show up. It's just that I'll have to completely redo the project file before I can make any more progress.
Attached:
Notable changes:
I've switched from using the generated XRC files to generated C++ files (wxFRED_base.cpp and wxFRED_base.h). This should allow coders to create their own versions of the wxFRED windows and dialogs by using class inheritance and OOP techniques. This should come in handy whenever a custom or less common widget is needed, such as a floating point spin control (spin controls are usually only integers) and a listbox tool on the FRED toolbar (the new ship type selection).
Windows, frames, and dialogs are named accordingly, so a dlgSomeEditor is expected to be something that has at least an OK button while a frmSomeFrame is something that has more oomph, same thing basically goes for all of the controls, such as btnOK, chkSomeFlag, etc.
All windows and editors are currently restricted to an initial size max of 800x600. It is expected that a number of frames and dialogs will be re-sizable, especially those with multi-line text boxes, such as the Mission Specs editor.
I currently have it setup so that child windows are referenced by their parent windows by way of pointers. The child windows themselves are instanced in heap memory, and should technically be able to run alongside other windows, such as highlighting waypoints in the main FRED window when you're using an editor on them, or real-time updating the position and orientation of selected object(s) from the Object Position/Orientation editor. Oh, and it should allow for better memory management in the future.
The home screen of wxFRED as designed in wxFormBuilder (note lack of the ship listbox):
The home screen of wxFRED, as seen on the first .exe:
Ship Editor:
Background Editor:
Asteroid Field Editor:
Mission Specs Editor:
Mission Specs Editor's Sound Environment child dialog (is also the progress photo just before the crash):
