Thursday, October 28, 2010

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 FileNameInserts 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 FileNameCreates 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!

Wednesday, October 27, 2010

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.

Sunday, October 24, 2010

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.

Friday, October 22, 2010

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.

Monday, October 18, 2010

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).