... so that my component "should" be plugin compatible with wxRTC. The idea is that I could develop the program such that on the one hand I can use wxRTC if this correctly works, and if not I can use my own component.
The development will again stall while I develop this new component, but hopefully not too long.
The custom control should be source code compatible so that I can use a preprocessore directive to decide which I will be using.
#if _USERTC_
#define MyCtrl wxRichTextCtrl
#else
#define MyCtrl wxScreenplayCtrl
#endif
then I should be able to develop using (MyCtrl *) ... in my code.
Time will tell
Sunday, 12 April 2009
Thursday, 9 April 2009
So we go with a Custom Control and Doc/View
So I decided to continue development using a Custom Control.
This would be descended from either a wxControl or perhaps a wxTextCtrlBase since this is a different text control.
Decided on the file format, and have decided on a new options dialog.
This would be descended from either a wxControl or perhaps a wxTextCtrlBase since this is a different text control.
Decided on the file format, and have decided on a new options dialog.
Saturday, 21 March 2009
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
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
Friday, 13 February 2009
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.
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.
Friday, 23 January 2009
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.
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.
Monday, 8 December 2008
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.
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.
Sunday, 7 December 2008
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.
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.
Subscribe to:
Posts (Atom)