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.