And unfortunately....

Changes in wxRTC between 2.8.7 and now have seriously screwed up my initiation code.

Unfortunately it doesn't look like I will have time to find out what caused the change, so I have given some thought as to the program.

Do I still want to do a Sophocles like program? Or should I make it more like a word processor? By this I mean should the user be allowed to change the background colour/font for the edit window? Why not? I decided to allow the user to do this, since I like it. It also means that the division of a screenplay can be easily seen. I am not sure exactly how I will implement this yet, but I think it should be do-able.

Do I stick with wxRTC or should I try and design a custom component? I actually think that a custom component will be the way to go here, since I should be able to design it in such a way that I can use it in wxWidgets doc/view system.

I'll need to give some thought to how best to do this, but I think attempting to push through some wxAui doc/view classes would be the way to go.

I'll have to start working on a doc/view program soon.

ttfn

Progress thy name is wxDev-C++

Moving along now.

I have added several components to the SVN-HEAD of wxDev-C++ which allows me to continue development of the main frame.

Currently I need to implement some sort of Auto-Completion for several styles. Character names certainly. How much further should I break the Scene Headers down? Should I have a single list? Break it down into several sections/lists? (INT./EXT. - Location - Time of Day)

I also need to think about which method will be the better? Should I present a ListBox with all options, or should I just fill in the nearest match and add the text to the editor?

I'll throw something together and see if I can present the two options, with screen shots.

Move along...Nothing to be seen here!

It's been a while, but I have added wxAui support to wxDev-C++.

So I should be able to move ahead with implementing the design of wxScreenplayWriter in wxDev-C++. I also need to add a wxRichTextStyleComboCtrl, a wxRichTextStyleListBox and a wxRichTextStyleListCtrl, but since these are basically simple enhancements to their base classes, this shouldn't take too long.

I also implemented wxAuiToolbar already, so unless I have missed something obvious (which isn't unheard of I must admit) I can already begin designing the GUI again. Since I have a working version of the GUI already, it shouldn't take me much longer to have it designed in wxDev-C++.

Also a great deal of the code can be cut and pasted into the new design, so hopefully I can move forward with the development.

My aim is to have the program in a useable position before the end of March.

wxDevCpp new components needed

OK, since I will be using the (almost) excellent wxAUI docking system, as well as the recently released wxAuiToolbar, I need to implement these in wxDevCpp as soon as possible.

At the moment there is a development stop with wxDevCpp since we are aiming for a release soon. After that we might stop developing altogether since we will be recoding the IDE in C++ and using wxWidgets in order to make the IDE and designer cross platform. I also want to extend the makefile support (at the moment only really good for windows systems IMO) in order to create projects for all system compilation (including a project for VS2005/8). The reasoning is this. GCC is the only real solution for cross platform compilation. It is used on all supported platforms. However, on Windows based systems, VS seems to reign supreme. Consequently we probably need to allow our future Linux/Mac users a simple and easy method of getting their project across to the windows audience.

I'll be investigating this later, initially I want to get the designer wxAUI compatible.

Changing designer

OK, I know it's been a long time but I have decided to move the design to wxDevCpp (http://wxdsgn.sf.net).

The reason is simple, I am one of the design team of wxDevCpp, whereas I was beta testing the wxForm designer. The consequence to this is that I have access to the source code of the designer, so I can extend it as I need.

This is the opposite to wxForms where as a user I have to wait until its author is able to implement changes and fix bugs.

Consequently I have decided to re-implement the current dialogs in wxDevCpp.

Unfortunately it doesn't have a very good debugger, so I hope to use the VS2005/8 IDE to do the debugging at a later stage.

Initially I need to get the program working as it was and then continue the development.

I have set myself the aim of having something usable before the end of the year. Perhaps not a fully functioning program, but something I can use to edit save and print screenplays.

Holiday Stop

Yeah, I know.

So much to do so little time.

Still, the holidays are looming and I still haven't worked on the autosuggestion for wxScreenplayWriter.

I don't believe I'll have the time before we leave for our holidays but if I do manage to work on the program, you'll read about it here.

Title Page Designer First Attempt

Here he is then. My first attempt at a title page designer. Based heavily on the title page designer from Blyte. (If you look carefully you can see a white rectangle to the right of the listbox - this will be a miniature representation of the title page)

I'm still not satisfied, but it does allow the development of the project without worrying that this needs to be done. I don't want my users to complain that something they desire is missing from the beginning. I might simply offer a series of wx(Rich)TextCtrls allowing the input of information, it would probably make my life a lot easier, but I like this design.

Next I'll work on getting the AutoSuggestions to work. These will be popup listboxes containing suggested lists.

The question is do I do several for the Scene Headings (one for Int/Ext etc, one for Location, one for time) or do I just do one list for the whole scene heading (or again do I allow the user the choice - more choices more programming, more complication for the user)