PEM Editor tip: Preferences Form changes / new options

This is a new feature in version 6.50.

The Preferences form has changed, somewhat, in that there are now 'Save' and 'Cancel' buttons, so any changes you make do not take effect unless you select 'Save'.  This is the design that always should have been there from the outset, of course, but maintenance of this form has always been at the bottom of the priority list.

This explains, in part, why I had gotten to the point where I so hated the thought of adding new features that required preferences, and also why there was so much work to do to use the new object (created as part of the re-factoring expedition), which handles all of the preferences.  Currently, there are about 135 preference items for it to maintain.

There are only a few new options in the new release:

Check out files using Source Control - 'General' tab, 'Processing' sub-tab.

Reset filters when opening another class or form - 'Filter Defaults' tab

New hot key Dynamic Snippets - 'Hot Keys' tab

PEM Editor tip: CreateLocalsStatements.PRG and orphaned Locals

This is a new feature in version 6.50.

There is a updated version of Plug-In 'CreateLocalsStatements.prg' in the 'Sample Plug-Ins' folder.  This Plug-In allows you to format your own Locals list in the way that you like.  (Apparently, there is great variety in this in the community, and some are very attached to the way they like their LOCALs formatted; I find this interesting, since once the list is created, I never want to see it again.)

This new version is an exact duplicate of what is done internally by PEM Editor, including references to the current preferences settings.  This allows you to tinker with the existing code to meet your own needs.

There are some new columns in the array which is passed in.  In particular, if Column 6 is True and Column 8 is False, then that row in the array refers to an 'orphaned' Local -- it appears in the list of locals, but is never assigned a value.  You could choose to have special formatting for such orphans (e.g., listing them separately, or even ignoring them altogether.)

PEM Editor tip: Plug-Ins may now be saved in your path.

This is a new feature in version 6.50.

For versions of PEM Editor before 6.50, all Plug-Ins were to be saved in the folder 'Live Plug-Ins', a sub-folder of the folder where PEM Editor is installed.

Beginning with this release, you may store your Plug-Ins anywhere that they can be found in your path (but see the note below)..  Doing so allows you to have the file backed up as part of your normal program backup.  Since the current folder is always searched first, this also allows you to have different plug-ins to apply to different folders.

Important Note: To avoid possible conflicts with existing code in your path, the names for Plug-Ins in your path must begin with the prefix 'PEME_'.  For instance, the Plug-In 'CreateLocalsStatements.prg' would have to be renamed 'PEME_CreateLocalsStatements.prg' to be found in your path.

PEM Editor tip: Using StartPEMEditor.prg

The 'normal' way for starting PEM Editor is to do so by using the menu items in the VFP Main Menu ('New Property ...', 'New Method ...', and 'Edit Property / Method ...'.)

There is an alternative to this -- StartPEMEditor.prg.  This file is created when you install PEM Editor (running PEMEditor.APP) and is found in the folder where PEM Editor is installed.

This can be quite handy, for a few reasons:

• It can allow you to set up your IDE programmatically. 
• It can allow you to bring up PEM Editor via a hot key.
• It can allow you.to access the IDE features of PEM Editor even if the PEM Editor form is closed.

StartPEMEditor.prg is compiled with a reference to the full path name where PEM Editor is installed.  Thus it can be copied anywhere on disk (presumably to somewhere on your path).  It can be called one of three ways:

1. StartPEMEditor() - brings up the normal PEMEditor form.
2. StartPEMEditor(2) - brings up the Document TreeView form.
3. StartPEMEditor(.Null.) - instantiates the PEM Editor object (_oPEMEditor), enabling the IDE features of PEM Editor, without opening either of the forms (This is a new feature in version 6.50.)
   
   

PEM Editor tip: Global Variable _oPEMEditor

This is a new feature in version 6.50.

The global variable _oPEMEditor (base class = Custom) is the container for all the forms and objects that are part of PEM Editor.

Since this a different structure than was used in previous versions (where _oPEMEditor had been the actual form), this means that any existing references to it will have to be changed.  Furthermore, a new version of StartPEMEditor.prg is necessary as well.

An immediate (although not obvious) effect is that all of the IDE features (available from the PEM Editor sub-menu in the VFP Main Menu) are now available, even if the PEM Editor form is closed.  This was one of the stated goals of the re-factoring process -- granting access to the IDE features to those users who do not choose to always have the PEM Editor form open.

There are also two objects in _oPEMEditor that will be made available to access various features with PEM Editor:

• _oPEMEditor.oEditorWin - a wrapper for the various functions in FoxTools, simplifying the process of manipulating the currently open editor window. 
• _oPEMEditor.oTools  - a collection of methods to access various others features.  At the moment, this list is small but will be added to by user request

Both of these objects will be of great value to those who look to customize and enhance PEM Editor, particularly in Dynamic Snippets and Go To Definition.  Documentation for these objects will be published -- well, in due time, when it is written.

PEM Editor tip: Where is the preferences file?

This is a new feature in version 6.50.

The file containing all of the PEM Editor preferences and settings is named 'PEMEditor_Preferences.DBF' and has been living in folder Home(7).

Beginning with this release, you may store the preferences file (along with its FPT file) anywhere that it can be found in your path.  Doing so allows you to have the file backed up as part of your normal program backup.

Note that you can reset all of the preferences and settings to their defaults by deleting all the records in the file and then packing it.

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.