Re-factoring PEM Editor: What ever was I thinking?

Since I started working on PEM Editor over two years ago, its internal structure has been essentially designless -- unless you consider a single form with over 200 custom methods and 200 custom properties as having a 'design'. 

I realize that this is not very uncommon as a project grows incrementally.  It's always so much easier to add one more item to the trashy design than it is to take the time to step back, create an appropriate design, and then implement that design.  So, it only got worse and worse over time. 

Of course, it wasn't a lack of recognition on my part that the internals resembled a vat of spaghetti, just that without a specific reason to do so, the time spent in re-factoring did not seem worth the effort (and, of course, would take time otherwise spent on adding and refining new features.)

But, right after SW Fox, when I began working on Dynamic Snippets (a result of discussions with Tore Bleken), I began to realize that there were capabilities within PEM Editor that could be beneficial if made available to other programs.  Later, in mid-November, an off-hand comment by Rick Schummer made be realize that opening up PEM Editor would have even more benefits. 

So, the next day, I started out.  It has turned out to be a boatload of work -- but, more importantly, I have gotten very good results.

The goals I set out for myself have been as follows:

1. Exposing the object within PEM Editor which handles the text within method code windows.  This relates specifically to the use of Dynamic Snippets.
2. Modifying the code for 'BeautifyX' so that it could be used elsewhere (and not just on code in a code window)
3. Exposing an object within PEM Editor which can accomplish some of its neat feats.
4. Making all the IDE features (available from the PEM Editor menu item in the VFP main menu) accessible even if the PEM Editor form is not visible.
5. Clean up the major disaster area of handling user preferences.  There are about 120 preferences items, and the problems with maintaining them (and their default values) made adding any new items to be amazing onerous.

As it happens, this re-factoring is more of a high-level task.  That is, in general what has happened has been that I have created a number of new business objects to handle the various tasks, and the changes in code have to do with making sure that the correct business object is referenced.  Except for those cases where I have identified duplications of code or places where newer techniques provide significant simplicity, the majority of changes in code have been to refer to methods and properties which have migrated to a different object.

Item #5 above, having to do with Preferences, was a nasty problem and took a LOT of work to resolve.  Eventually though, I created a really nifty (and simple) object which handles all the preferences.  This little object gets passed to all the other objects, and so the nasty problem has now faded into the past.

At this time, I have done all the major re-structuring to allow completion of my goals, and will be releasing a test version in a few days.  While there is still work to be done on the first three goals, I am now over all the major hurdles.  And, I must say, will know to consider very carefully the next time that the topic of re-factoring cross my mind.