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.

PEM Editor tip: Setting default values for properties

By default, PEM Editor uses Hungarian notation for property names, where the first letter is lower case representing the data type of the property.

If this is not the behavior you desire, you can use or modify a Plug-In PRG. Copy GetDefaultValue.PRG from the 'Sample Plug-Ins' folde  to the 'Live Plug-Ins' folder. This PRG uses the second letter of the property name to determine the data type.  If that is not what is desired either, modify the PRG as necessary to fit your needs.

Finally -- if you always want your new properties to be assigned a default value of .F., de-select the option on the Preferences Form ('General' tab / 'Processing' sub-tab)

PEM Editor tip: Creating LOCAL statements

The Create LOCAL Declarations function of PEM Editor is a huge timesaver. It traverses the currently open method and creates a LOCAL statement for all variables that have been assigned there.

It can be accessed in one of three ways:

• From the 'PEM Editor' menu item in the VFP Main Menu
• By using the hot key you have assigned to it (click the Preferences button, select the Hot Keys page of the Preferences dialog, select the BeautifyX & Locals subpage, and remove the “*” at the start of the hot key for Create LOCAL Declarations or enter the key you want to it to be defined as.)
• By including it automatically when you run BeautifyX (same LOCALs subpage as above, but select 'Create LOCALs as part of BeautifyX')

The LOCALs subpage of the BeautifyX page of the Preferences dialog even allows you to configure how the LOCAL statement looks.

For even more control, copy CreateLocalStatements.PRG from Sample Plug-Ins to Live Plug-Ins; that program allows you to code how the statement should look. For example, some users like the variables to appear in LOCAL in the order they appear in the program, while the default behavior of CreateLocalStatements.PRG is to sort them alphabetically. Fortunately, that’s easy to change: comment out this line:

Asort (laLocals, 1, -1, 0, 0)

Reporting bugs in PEM Editor

If you should be unfortunate enough to get a bug in PEM Editor, you'll see that the only information that the debugger provides is the annoying message "Source not available".

This occurs because PEM Editor is compiled without any debug information, in acknowledgement of those users who have PEM Editor and the debugger open at the same time.  (If PEM Editor is open when the debugger is open, performance slows to a crawl.)

However, you can cause PEM Editor to be re-compiled so that it includes debug information, so that you can report in much greater detail what the error is, where it occurs, and what the values of relevant variables are.  The steps are:

1. Close PEM Editor and Document TreeView
2. CD to the 'Source' sub-folder of the folder where PEM Editor is installed
3. Execute the following line:
   

   BuildPEMEditor(.T.)

Then you can CD back to your original folder, re-open PEM Editor, and reproduce the error. 

EMail as much information about the error as possible to Jim Nelson.

If you need to re-compile PEM Editor so that debug information is excluded (because you use it with the debugger open), you can later repeat the above statements, omitting the single parameter to BuildPEMEditor.

PEM Editor: @New simplifies adding new snippets

This is a new feature in version 6.20.

There is a new snippet, @New, which is used to create a new snippet.  When invoked, it displays a form that looks like this:

When you have filled in the Snippet Keyword, you will be able to create the new snippet.  The PRG will be saved and opened at the place where you will want to add your own code for the snippet.

Note that you should also modify the function <PublishHelp> so that the @Help screen displays the syntax and description of your snippet.

PEM Editor Tip: New feature for Navigating to Parent Classes

This is a new feature in version 6.20.

A constant and unavoidable frustration occurs when you find that you need to work on a parent class for the form or class you are editing (or one of its members).  What you need to do, of course, is to close the form or class you are working on and then find and open the parent class. This new feature simplifies the task of finding and opening the parent class, so that it can be done entirely within PEM Editor.

These are the few steps to be followed:
(1)  Make sure that PEM Editor is displaying the form/class/object whose Parent Class you want to open.
(2)  Open the context menu from the combobox, and select 'Save Parent Classes'.

(3)  Close the current form or class.
(4)  Click on the 'Open' icon at the top of PEM Editor. Under the menu item 'MRU Parent Classes' will be listed all the parent classes (all of them ... all the way back), and you can select which Parent Class you need to modify.

PEM Editor Release 6.20 (Alpha) Release Notes

This release contains a number of small, localized enhancements, listed here in no obvious order.

As always with an Alpha release, remember that this code is very new.  It is submitted for your testing, review, and comments.  Use at your own risk.

You can download this release from here.

This release deals primarily with Dynamic Snippets.  (For the original discussion about Dynamic Snippets, originally called PMDs, go here.)

Dynamic snippets are a new IDE tool that allow you to create macro definitions that you can use when writing code which will insert text based on parameters that are passed (for example, entering @F Alias inserts the names of the fields from the table/cursor Alias.)

The basic concept is that in any code window (method code, PRG, or command line), you can enter a sequence of four things to activate a snippet:

• The snippet-identifier character (default is @)
• The snippet-keyword (usually an abbreviation, like 'F' above)
• The parameters that the snippet keyword will act upon
• And then the snippet Hot Key.

So, the first step is to activate the Dynamic Snippet Hot Key -- go to the Hot Keys tab on the Preferences form, and double-click on the textbox for Dynamic Snippets.  This activates the default key (F5).  You can choose any other key, should you wish, but just be aware that it must be a key that can be defined with ON KEY LABEL.

The next step is to access the Snippet Help screen.  Enter  @Help (or @?) in any code window, and press the Hot Key.  This list shows you all the defined snippets, the parameters they expect, and a detailed description (if appropriate).  Initially, you will only see the few snippets  that are built in to PEM Editor.

However, an inherent part of the design of Dynamic Snippets is that you can easily create your own.  There are quite a few samples provided (including those that duplicate the behavior of those built in to PEM Editor). For a full description of how to create your own, see Create your own Dynamic Snippets

Note that as you modify the sample Dynamic Snippets, or create your own, they will always appear in the snippet Help screen.


The following items were released previously in Version 6.11.01:

• Go To Definition has been enhanced to simplify the process of creating new methods and properties as you are writing code.  
• Enhanced Ctrl+X and Ctrl+C have been enhanced so that the copied or cut text can be added to the clipboard instead of replacing it
• There is a new option in the right-click context menu for the combobox to add new objects to containers (forms, pages, containers, and columns).
• A new option has been added to the preferences from for standardizing string delimiters -- brackets are now provided as one of the alternatives.

PEM Editor Tip: Creating your own Dynamic Snippets

Custom Dynamic Snippets are defined by creating PRGs in a particular folder.  The PRGs take a single parameter, return a simple result, and are generally stand-alone.  There is a template snippet that you can rename and edit as needed for new snippets.  Reading (or modifying) existing snippets would, of course, be of great assistance in seeing how they work.

The PRG files that PEM Editor looks for are named PEME_Snippet_*.PRG, where the '*'  matches the name of the snippet-keyword that the PRG handles.  The PRGs may be in the current directory, anywhere in the path, or in the sub-folder (named 'Dynamic Snippets') of the folder where PEM Editor is installed.

There are a number of sample PRGs in a sub-folder (named 'Snippet Samples'). These samples include the exact code used for the Dynamic Snippets that are built in to PEM Editor. All of these samples can be activated simply by copying the entire contents of the Samples folder into the parent folder ( 'Dynamic Snippets').
Dynamic Snippets have been designed in such a way that it is simple both to perform the desired task and also to publish its description (that is, what you see from @Help).  There are three distinct sections in each PRG:

First Section: Compile-Time Constants:  Four constants which identify the snippet-keyword, and how the remainder of the snippet is to be split into parameters for the 'Process' function (see below).  These identify the delimiter between parameters, and the minimum and maximum number of parameters that are acceptable.

Middle Section: Setup and Cleanup Block: A block of code that handles passing of parameters, etc.  Skip this; it shouldn't be changed.

Last Section: Custom code for this snippet: This section, at the very end of the PRG, contains the following two functions: 

Function 'Process', which is called if the snippet-keyword for this PRG matches the keyword that was entered in the code window.  This is the procedure that you will modify to actually do the work of the snippet.

The text following the snippet-keyword will have been broken into a list of parameters, and this function is called with these parameters, as character.  The result is to be one of:

•  a character string -- which will replace the snippet entered in the code window.  The sub-string '^^^' is used to indicate where the cursor is to be placed.  (The default is to place the cursor after the inserted string.)
• .T. -- if the string was handled by the PRG, but the Snippet entered in the code window is not to be touched.  (See, for instance @Sel, which modifies the code window itself and then places the cursor appropriately)
• .F. -- if the string was not handled by the PRG

A simple example of this is found PEME_Snippet_UC.PRG, which creates a case-insensitive comparison of two strings.  Here is all the code:

* Top Section
    #Define Snippet_Keyword     UC
    #Define Delimiter_Char      '='
    #Define Min_Parameters      2
    #Define Max_Parameters      2
  
    * Bottom Section
    Function Process
        Lparameters lcText1, lcText2
        Return 'Upper(' + lcText1 + ') = Upper(' + lcText2 + ')'
    EndFunc

Function 'PublishHelp', which is used to publish the syntax, summary, and detailed explanation that appear in @Help. 

Additional Notes:
There aren't really any limitations to what you do within the procedure 'Process'.  You can add procedures and funtctions to the PRG, call dialogs, open external forms, etc.  You can also modify the text in the code window directly, using _oPEMEditor.oEditorWin, which is an object containing cover functions for the tools in FoxTools.fll.  (Documentation on this is not yet available.)

To simplify the task of debugging snippets, you can invoke directly them, even if PEM Editor is not running..  Just call them with a single parameter, equivalent to the character string which follows the snipper-keyword..  The result should be the replacement character string.  Once they work correctly when invoked directly, they should also be available for immediate use as a Dynamic Snippets.

Special Day for the PEM Editor Guy

Today's a special day for me -- the first digit on the odometer flips over to a six.  (I am particularly glad I am only as old as I feel, and not as old as I look.)

I have been particularly lucky throughout my life, in many, many ways, which I will not enumerate here -- other than to say that the good friends that I have gained because of this peculiar project that I stumbled upon two years ago have been a wonderful addition to my life.

JRN

PEM Editor Tip: Working with more than one form or class open

This is a warning about a possible trap you can fall into when you have two or more forms or classes open at the same time.

The point is this:  When you click on a method code window, PEM Editor (like Property Window) does not recognize what form or class it belongs to.

This is very important for PEM Editor, because if you then either use PEM Editor directly (e.g., to add a property or method), or indirectly (using some of the IDE tools), you may be making modifications to the wrong form or class.

(You can reproduce this behavior for yourself.  Open up FormA, method MethodA.  Then, open up Form B, method Method B.  Now click on MethodA -- PEM Editor, like Property Window, still shows FormB!)

The remedy for this is simple enough. The title caption for PEM Editor shows what form/class it is working on.  If you are editing a method code window, and the title caption in PEM Editor does not match, then click on the form / class you are editing, and PEM Editor will get in sync.

Two final points:

1. You may have noted that PEM Editor changes the title captions for forms and method code windows, for your enlightenment.  In particular, if you have a form/class open and also open a backup code of the same form/class, the title caption in each helps you distinguish between the current copy and its backup.
2. PEM Editor does not actually know when you have two or more forms/classes open.  It only knows about the current form/class, and has no way of knowing about any others that are open but not active.

PEM Editor - Parameterized Macro Definitions (PMDs)

One of the more popular requests I have seen over time (not related to PEM Editor in any way) is a way to insert the list of fields from a cursor into method text that you are editing.

There have been alternatives suggested over time.  Parameterized Macro Definitions (ugh, what an ugly name!) offer a new approach to this problem, a new simpler way to implement the solution, and a mechanism for creating an unlimited number of other definitions.

First an example:  

Suppose you had a cursor (or table) with an alias of SomeName, and you wanted to insert into your method code the list of all fields in SomeName.  With PMDs, you would enter:

Select ##Flds SomeName

and then press the associated hotkey.  The odd -looking text beginning with ## is then replaced with the list of fields from the cursor.

So, what is going on?

• ## is the marker for the beginning of the PMD.  
• Flds is the PMD keyword (case-insensitive)
• SomeName is the parameter which will be passed along to the sub-routine for processing

When you press the hot key (right now, Alt+3 is the recommended choice), PEM Editor looks backward thru the current line for the ##, finds the keyword, and then calls the appropriate sub-routine to process the keyword.

Planned PMDs	Description
## Flds FileName	Inserts the list of all fields from FileName, one per line, as would be used by SQL-SELECT. Qualifiers may be added later, to allow for searching for the file (if not open) and to insert an alias before each field name
## From FileName, ID=OtherFile.ID, etc.	Inserts a FROM statement (for SQL-Select) and related JOIN statements; e.g., From Filename Join OtherFile on Filename.ID = OtherFile.ID
## LS FileName	Creates a new window to display the structure for Filename
## ?	Creates a new window to to display a list of all PMDs (much like this list

Create your own PMDs

The neatest thing about this is that you can create new PMDs very simply, by adding creating new Plug-Ins.  The code is very easy to write (the PRG is passed the keyword and parameter, and returns the text to be inserted).

Furthermore, the code for each of the PMDs to be included here will be available in the Sample Plug-Ins folder.  You will see there is precious little code, and it's not very sophisticated at all.  You may even want to modify it (for instance, if you don't like the way the field names are created for ## Flds.)

All that needs to be done is to create a PRG named HASH<something>.PRG into the the Plug-Ins folder, follow the structure and comments from the samples, and you can create your own PMDs, working on their own keywords.

This is not quite ready for use (unfortunately).  Look for release 6.11.003 soon. Possibly this weekend if all goes well.

Many thanks to Tore Bleken on this one.  He posted the original suggestion and through a succession of emails we arrived at the the design described above.  Thanks, Tore!

PEM Editor Tips

One of things I intend for this blog is to publish tips from time to time about features in PEM Editor.  I assume that there are many features that are not used for a variety of reasons:  people are not aware of the features, or don't know why they would use them, or don't know how to use them.

Thus, from one to time, I intend on posting tips about PEM Editor.

So, if you have questions about particular aspects of PEM Editor, please send a comment so that your question can be answered, and others will be able to learn as well.

PEM Editor Release 6.11.01 (Alpha) Release Notes

This release contains a number of small, localized enhancements, listed here in no obvious order. 

As always with an Alpha release, remember that this code is very new.  It is submitted for your testing, review, and comments.  Use at your own risk.

You can download this release from here.

(1)  Go To Definition has been enhanced to simplify the process of creating new methods and properties as you are writing code.  

When you use Go To Definition (either by using a hot key -- suggested as F12, or from the pull-down menu), and the name you are searching for is not found, PEM Editor will ask if you want to add it as a new property or method.  Thus, if you have entered the following (referencing a not-yet defined method),



You can then press F12 (Go to Definition) and you will be given the following options:

If you create a new method, as you can see, you can begin editing it immediately.  You can return to the original method you were editing by pressing F7 (previous)

If you create a new property, it is created with its normal default value.  It will be the currently selected property in the PEM Editor grid, if you need to make any other modifications to it (description, etc.)

(2)  Enhanced Ctrl+X and Ctrl+C have been enhanced. (Yup)

There are new variants for Enhanced Ctrl+X and Enhanced Ctrl+C (suggested keystrokes Alt+X and Alt+C respectively) which append the selected text to the clipboard instead of replacing the contents of the clipboard.  This allows you to build up the clipboard by a series of selecting/copying actions.  Note that these new variants are referred to as 'Additive'.

(3)  There is a new option in the right-click context menu for the combobox to add new objects to containers (forms, pages, containers, and columns).


This option has been added specifically to simplify adding objects to columns of grids. Note it uses PEM Editor's 'Find Class' screen, modeled after the search screen in Code Reference. 

 (4)  A new option has been added to the preferences from for standardizing string delimiters -- brackets are now provided as one of the alternatives.

Suggest New Features for PEM Editor

Please feel free to add comments to this page to suggest new features.

No item is too small or too big to be considered.  Release 6, for instance, grew out of a single tiny suggestion from Matt Slay.

PEM Editor Items Under Consideration

This page is reserved for discussions of ERs that have been suggested for inclusion in PEM Editor.

I ask that you limit your comments here to items that appear on this page.  Eventually, of course, if all goes well, they will move forward to Planned Enhancements, and then eventually be implemented.

Please feel free to comment on the items listed here.  To make any other suggestion, please use Suggest New Features.

• On the form for editing properties when multiple objects are selected:
• Combobox for selecting properties/methods to add as columns.
• Ability to sort on columns.
• New checkbox column to select a sub-set of objects found; then be able to
• Reset a particular property/method to default for all checked rows
• Set the same value for all checked rows.
• Change Parent Class (to same) for all checked rows
• BeautifyX enhancements:
• Add M-Dot (m.) to all locals (for my good friend Cesar)
• Remove leading * from code lines
• Search method code.  A replacement for Ctrl+F; produces a grid result like that of Code References.  
• Regular Expressions
• Continuation lines
• Can select the method from the grid, or the object it belongs to
• Extend Document TreeView to apply to PRGs as well. Completes the replacement for native Document View.  Some technical issues remain.
• Provide interface to Beyond Compare to compare two methods or, possibly, even two classes or two forms.  Details still sketchy.  (Beyond Compare does a great job with VCXs and SCXs; this suggestion would apply to classes, instead of class libraries, and available when the class is open)
• Putting SQL-SELECT statements into a standard format.  That is, re-arranging the phrases into the standard order, on new lines as appropriate. 
• New IDE feature:  Extract to Local takes highighted text, prompts for a variable name, creates a new line assigning the highlighted text to the variable name, and then changes all references to the highlighted text to be the variable name, 
• Further enhancements to Locals: 
• Option to create locals list in order of first occurrence (rather than alphabetical)
• Option to handle 'orphaned locals' -- names listed as LOCAL that are never assigned:
• Keep 'em as locals (this is what happens currently)
• Remove them altogether.
• Add them on their own LOCAL statement, with a following comment indicating that they are orphans
•  New listing, showing all code and parent code for all objects.  Uncertain at this time how to present this information, as it is not clear how to present all the code in parent classes when the same parent class occurred multiple times (requested by Rick S. -- awaiting his input)
• Document TreeView displays correctly for formsets, but does not function properly -- it does not select an object properly, nor does it open method code properly.

PEM Editor Planned Enhancements

This page is reserved for ERs that are planned for inclusion in PEM Editor.

"Planned" is somewhat inaccurate, though.  "Intended" is probably closer.  The intent is that items that appear here will be included in PEM Editor, at some un-promised time in the future, when all technical issues have been resolved.

Please feel free to comment on the items listed here.  To make any other suggestion, please use Suggest New Features.

• Extract to Method should append the normal function header (via plug-in)
• Extension to Go To Definition (code courtesy of Doug Hennig)
• Search through #Defines and #Includes for constant definitions
• Search through PRGs for Procedure and Function definitions
• Source Code Control (idea courtesy of Bhavbhuti Nathwani)
• MRU menu items and 'Open' forms can conditionally check out items from SCC.
• Modifications to Change Parent Class
• List of items to paste should include all non-default properties and methods as well as any properties, even if default, which are different between the two objects.

PEM Editor and Fun

Very very early in this project, my good friend Cesar Chalom told me of his own work in FoxCharts.  Not knowing what I was eventually going to get myself into, I asked him why he had spend so much time on his own project.  His explanation was simple ... "It's been a lot of fun!  It should always be fun!  When it stops being fun, I will quit!"

When I was in college, my goal was to teach mathematics at the university level.  When I learned that the likelihood of actually getting such a job was exceedingly slim, I left after getting a Master's.

Nonetheless, I have always delighted in solving problems.  Sudokus, crosswords, Games magazine ... I still have a book from high school with the title "Mathematics is Fun".  I have another which contains the memorable quote "Numbers are our friends" in the preface.  In my family, my brother's line "there's a math problem everywhere" was a wonderful acknowledgment of the joy we all feel in solving those problems.

Which is all to say that I enjoy challenges where the fun is conquering the challenge, regardless of utility of the result.  (When I finish a sudoko that I have proudly wrestled with and won, I still just throw it away.)

And PEM Editor has provided an endless array of challenges.  I have learned an awful lot about VFP because of it -- but there is a lot more to it than that.  There have been suggestions that I have hung on to for ever six months, waiting until I had accumulated both the technical skills and also the perspective to see the problem in the correct light.  I have been given explicit challenges where I was told I could not do something.  And I have come up with new combinations of the tools I have created to create what others have not even suggested.

Ah, it has all been worth it!

Why PEM Editor?

I've been asked what in the world motivated me to start (and continue) this project.  If you're interested, here goes:

At the of SouthWest Fox 2007, I flew directly from Phoenix (95 degrees) to Denver (25 degrees, blizzard).  I was stranded in my hotel all day that Sunday.

I began looking through the conference materials, and happened upon some open source code for 'New Edit Property/Method Dialog' by Marcia Akins.  I decided to dig into it for two reasons: first, I was not aware of and did not use the original VFP version (talk about being a newbie!) and I thought I could learn a lot from reading an expert's code.  I decided to challenge myself by adding a column to the grid.

I promptly broke it, could not fix it, and could not reverse its installation. This was not a big issue to me, since I had never used it before anyway.

Fast forward to SouthWest Fox 2008.  I attended the VFPx session, at which I (uncharacteristically) commented that many of us less experienced developers did not feel that we had really had anything to contribute.  Nonetheless, the next day I submitted a suggestion topic for VFPx about the coverage profiler.

While waiting for the response, I happened to notice a post on the UT, from a guy named Matt Slay, a no-name like myself, about the very utility I had looked at the previous year (and had continued to do without).  I decided to try digging into it again, to see if I could re-install it, learn how to use it, add in what Matt had done as well, as well making the little modification I had first considered, that of adding a column.

It turned out not to be that difficult to do, so I messaged Matt, telling him what I had done, and commenting that any time I worked with a grid with that many rows, I would certainly add column sorting and probably some filter mechanism (such as property vs. method).  That was my mistake.  Matt responded with great enthusiasm and we were off to the races.  Within a few days, he noted another post on the UT mentioning some issues that we could investigate, which led is to meet Cesar Chalom (Brazil) and Carlos Alloatti (Argentina).  Within a week, the four of us had an ER list of over 40 items.  I was absolutely sure most of them could not be done (and certainly not by me).  I was completely wrong.

A digression here:  There were a unique combination of circumstances at work here, a WOO (Window OF Opportunity) not to occur again:

• The project itself was a combination of two parts: a especially simple UI, and a really complicated back end which few, other than Marcia and Doug Hennig, really understood.  There were lots of improvements that were made early in the UI (much more flash than substance) which appeared really impressive, but demonstrated only rudimentary VFP skills.  This allowed me to get into the back end gradually.
• I had a really enthusiastic and competent co-conspirator, Matt Slay.  While it is true he has only written a few lines of code in PEM Editor, it never would have happened without him.  Over the course of the next five or six months, we both worked an unbelievable number of hours, as he contributed comments, suggestions, testing, etc .... the perfect partner for a project like this.  I must say that he has not been given the proper credit for his part in this project, and I would like to do the best I can to rectify that.
• For possibly the only time in my professional programming career (ahem, going back to 1973), I had an extended period of time where my paid work had pretty much come to a stand-still.  As an employee,  I did not have to worry about my paycheck.  And, I felt perfectly comfortable in getting back some of the long hours I had worked earlier for the same employer.
• Finally, coinciding with my work on PEM Editor, my wife was away from our home, helping our daughter (who was in Palm Springs).  For the next three months, I was essentially home alone.

PEM Editor version 2 was released to VFPx only about three weeks after my first conversation with Matt.  Things continued at a furious pace well into the first few months of the next year.  By then, the project was self-propelled.  Curiously though, I was more motivated by the enthusiasm of my support staff than by own need, as I really did not start adding features that I found valuable until I started working on version 4.

So, this has been a little history behind how PEM Editor started.  Why I have continued is the subject of another post.

P.S.:  About that suggestion for the coverage profiler.  Doug, Rick and Craig dropped the ball on it, and did not respond to the request until I off-handedly mentioned in many months later.  We are all glad they did.

PEM Editor and VFPx

PEM Editor is one of the projects in VFPx, a Visual FoxPro community effort to create open source add-ons for Visual FoxPro 9.0.  It has been part of VFPx since at least 2007, with the release of "New Edit Property/Method Dialog...", and then all of the following releases thru release 6 in September this year.

VFPx is a fantastic source of tools for the VFP developer.  Since all the tools are free, you have every reason to visit VFPx regularly to keep up to date with what is going on there.

While VFPx is a great repository for VFP tools, it has not proved to be an efficient forum for the discussion of enhancements for these tools.  For the two years that I have been product manager for PEM Editor, there have been only a few messages in VFPx with suggestions for enhancements to PEM Editor (well, a few bug reports too).  During the same time, there have been thousands of emails between those interested in its development.
I believe that this occurs because involving the entire community in all the details (some agonizingly minute) is counterproductive.

Thus, I have created this blog for those interested in following the details of PEM Editor in more detail.  This blog will not replace VFPx, it will merely augment it.  What will be available here will be the discussions about all new features, giving opportunity to comment on them early.  All Production and Beta releases will still be made on VFPx.  What you will see here will be all the incremental changes along the way -- yes, sometimes multiple updates on the same day.

Blogging about PEM Editor -- Finally

I've just returned from SW Fox 2010.  For me, it was the best of all the SouthWest Fox conferences (I've attended all seven of them) both in what I gained from the sessions themselves and also because of  the people I met and got to know.

I was most heartened by all the gracious comments made about PEM Editor, my hobby for the last two years.  As it happens, it seems people take the time to express their gratitude when they meet you in person a lot more frequently than they do otherwise. Lots of attendees approached me, speaking well of PEM Editor and thanking me for my work. I really appreciated that, although, to be honest, I have never thought of it as work -- everything I've done on it has been for fun.  I've learned, from my good friend Cesar Chalom, that it's time to stop when it's no longer fun.  And I'm not there yet.

I decided to blog about it for a few reasons:  to provide a place for discussions about suggested enhancements, for further descriptions and examples beyond what is in the help file (including examples provided by others), and (ahem!) maybe some more collaborators might show up for testing, documentation, etc.  (I can always dream).