If you look at the schematic you'll see there's 2 main sections. The GUI and the DB stuff.

Rule 1. Keep the Database and GUI seperate. I want to do this so that i can make different front ends later and not have to try and seperate the code ie, for analysis programs. Here's a list of the current classes and their functions.

• myFrame
• Sql_Connect_dlg
• sm_glob
• LANG
• DB_Master
• DB_Base + others.

And some others i've thought about but not quite sure where they should go yet.

myFrame

This is the basic entry point for wxWidgets. It defines the main window

Sql_Connect_dlg

This is my MySQL test dialog. It doesn't do anything and is about to get revamped into something a lot more useful

sm_glob .. an abbreviation for Stockmonster Globals

This is just a place holder for anything that's semi Global. I don't like Global Variables so i put them in here. The only downside is that it has to be inherited by any class that needs it's functions, which unfortunately creates a new instance and wipes out the data already in it. I'd like to make it static, but that has it's drawbacks too. I need a better way of doing this, but until i can work it out this is where it lives.
 

LANG

This is my first attempt at making something user and country friendly. Basically all strings in the GUI will come from here, that way we can customize the strings for any language and slang we want. I've made it quick and dirty at the moment so it will require some attention pretty soon. LANG holds all the GUI enumerated ID's i put them here to make associating strings easier, ie the identifier ID_Help  then when we create the string line line reads

str[ID_Help]="Help";

This way when adding the menu it reads

menuBar->Append(helpMenu, _T(lang.str[IDM_HELP]));

DB_Master

This is the database master class. The aim of this class is to hide everything that's underneath it. All calls to the databases are to eventually be made by this class. The reason for this is that i want to be able to use multiple databases, even update multiple databases simultaneously.  Also it could be used to intelligently select which database to get data from ( ie, the quickest ), also you might only have the histories for one country but might decide to look at something not currently in you Main Database, DB_Master will look it up on the net for you and can even add it to your main database.  Currently i have it set on 5 but that may change or i could make it dynamic when i have time.

Other functions that will be good would be

• Copy_DB(fromDB,toDB);    // need to filter. We don't want stuff we already have or stuff we don't want.

DB_Base + others.

This is the Base class for all the derived database types most functions are virtual and will eventually become pure virtual. There is some overhead doing this but it's the simplest method. All databases will contain certain common features ie, Add Get Set etc.

Current Database types are

• MySQL - use a MySQL database on the users machine.
• Internal - use the internal database on the users machine.
• External - Connect via internet to a SM server or possibly client.
• ODBC - Any old microsoft / Win32 database.
• Metastock - accesses the Metastock database. Should be used in write only as the metastock file system doesn't allow as much data as the others.

I'm also quickly coming to the conclusion that the best place to call an option dialog from these classes is from within these classes. I didn't want to do that though as it would break Rule 1, HOWEVER, this will be ok as the dialog could be generic and used in future wxWidgets programs derived from this, that would actually be a bonus. Also it would allow anything that's database specific to be allowed to live more easily.

P2P

The P2P class is tricky. I am thinking about making it a client underneath DB_Base since most of it's work will be connecting to another computer and downloading data. However if we expand the function of P2P to add in chat's or "Instant Messages" then there would be no way of getting these out from the DBMaster class without breaking Rule 1. Again though as above

Script

The scripting engine is the next stage. Currently it'll be a simple class which will just be a transfer protocol between the classes. That should let me download a page from the internet, decode it and then write the components to a database.