PEMEditor BeautifyX comments

Topics: Bug Information, Enhancement Request
Apr 6, 2011 at 6:27 PM

First, I've been using PEMEditor for quite some time now and really appreciate the effort that's gone into it. Based on a recent thread over in ProFox, I decided to check out the ability to create LOCALs in method code and have a few comments/questions.

I prefer to have keywords in CAPS. The local declaration created by using this feature proper cases the word "Local". Is there a way to get "LOCAL" instead?

I prefer to have all memvars prefixed with "m.". The local declaration created by using this feature doesn't do this. Is there a way to get "m."?

The option to use 'AS datatype' does not appear to work if the multiple variables on the same line is checked.

If creating LOCALS as part of running BeautifyX, the GLOBAL comment always gets added potentially resulting in multiple instances of the same comment.

I prefer to not have spaces around = or +. Can that be added as an option?

I'd be willing to make a contribution to adding or enhancing this project but am not quite sure how to go about it. I will poke around a bit to see if I can answer my own questions but feel free to point me in the right direction... <vbg>

Thanks again for continuing to enhance this great tool!

Coordinator
Apr 6, 2011 at 8:04 PM

PEM Editor allows for customization by providing a number of different plug-in PRGS.  Samples of these are found in folder 'Sample Plug-Ins', and are activated by copying them into the 'Live Plug-Ins' folder.  Each of the samples are fully commented so that you can understand their purpose, parameters, etc.  In general, the samples provided duplicate the default behavior of PEM Editor.

The PRG you are interested in is CreateLocalStatements.PRG.  It is called with an array as a parameter, containing the list of all names which are to be included in the LOCAL statement(s).  Its result is a character string.  You should be able to modify this PRG to attain the exact display as you would like it to appear.  (Curiously, it seems that there is wide disparity among developers about the appearance of LOCAL statements, as I am asked about this quite frequently).

You have also mentioned the spaces around '=' and '+'.  This is controlled in the preferences form, under the BeautifyX tab.  It would be well worth your time to investigate the wealth of options there for BeautifyX.

Jim Nelson

Apr 6, 2011 at 8:17 PM

Thanks, Jim. I'd forgotten about the plug-in mechanism. I'll take a look at that prg. (And let's not start talking about tabs vs. spaces... <g>)

I did explore the options before writing here and there is indeed a wealth of options; I just missed the one called "add space around operators"... Doh!

Apr 6, 2011 at 10:17 PM

Tweaking that prg got me most of the way there. There's a little bit of odd behavior when running beautify in a method with no memvars at all. It still inserts one local declaration that perhaps should no longer be in scope. I can try to provide more details if you want.

BTW when I opened the project on my system, it asked me to locate findcomp.gif. Looks like that's missing from the zip.

Coordinator
Apr 6, 2011 at 10:25 PM

What version of PEM Editor are you using?

Perhaps you could send an example of the problem with the method with no local assignments so that I could see what you are experiencing.

And I really don't know about the problem with findcomp.gif, since it exists in the images folder, like all the others.

Jim

Apr 7, 2011 at 2:29 AM

6.10

What's the best way to get you something?

I just pulled up an old test form. There are 2 methods with code. One has a single memvar in it. The other has only form refs. I hit F6 on the first one and it stuck in the global comment. When I hit F6 on the second one, it inserted the global comment again even though that memvar is not referenced in the 2nd method; hence my suspicion that something that should be out of scope is still in scope.

My best recollection is when I got the zip from VFPX back in November, I unzipped it and that's it. For some reason, that gif is not in the images folder created when I unpacked it. I'll go grab a fresh copy and see what's there.

Coordinator
Apr 7, 2011 at 3:00 AM

My email is JimRNelson@GMail.com

That behavior you describe IS odd, very odd indeed.  I'll look into it tomorrow.

As for the global comment -- you know you have control over that in the plug-in PRG, right? 

Apr 7, 2011 at 12:12 PM

Maybe I'm misunderstanding how the global is supposed to get inserted. My assumption is it happens when there are memvars referenced  in the method code being processed.

I'm working from home today so it's a little difficult to send you the test form. So here's some snippets:

form init:

*:Global x

x=GETFILE('DBF', 'Pick a .DBF:')
thisform.cursorname=justfname(x)

command1.click

*:Global x

wait window thisform.cursorname
use(thisform.cursorname) in 0
select(thisform.cursorname)
wait window DBF()
use in thisform.cursorname
wait window

My expectation is that the init should have the global comment while the command click should not.

I downloaded the latest source from VFPX. When I looked in the zip, that gif is not there.

Coordinator
Apr 7, 2011 at 1:39 PM
The idea behind the 'global' comment line is to identify which variables are assigned but are meant to be left global. The assumption is that you don't want these to be localized (because they don't start with lowercase 'l'). But that doesn't seem to be the case for you, at least in this example.
It appears that you are using the second item in the combobox that controls this (on the locals tab in the preferences form). It seems more likely, from your little snippet of code, that the third item might be more appropriate.
In any case, with the option you are using, there is no attempt at maintence of the *:Global line(s) -- they are not removed, for instance, and as you noticed, when you run it again, they get repeated. This can be corrected, I guess, if you find it troublesome.
I will see if I can duplicate the problem of the *:Global comment being carried forward to the next method -- whew, that's quite bizarre.
Jim
BTW -- file is attached


On Thu, Apr 7, 2011 at 5:12 AM, rkaye <notifications@codeplex.com> wrote:

From: rkaye

Maybe I'm misunderstanding how the global is supposed to get inserted. My assumption is it happens when there are memvars referenced in the method code being processed.

I'm working from home today so it's a little difficult to send you the test form. So here's some snippets:

form init:

*:Global x

x=GETFILE('DBF', 'Pick a .DBF:')
thisform.cursorname=justfname(x)

command1.click

*:Global x

wait window thisform.cursorname
use(thisform.cursorname) in 0
select(thisform.cursorname)
wait window DBF()
use in thisform.cursorname
wait window

My expectation is that the init should have the global comment while the command click should not.

I downloaded the latest source from VFPX. When I looked in the zip, that gif is not there.

Read the full discussion online.

To add a post to this discussion, reply to this email (VFPX@discussions.codeplex.com)

To start a new discussion for this project, email VFPX@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Jim Nelson
(805) 498-9195 (voice + fax)
(720) 837-3536 (cell)
Apr 7, 2011 at 3:04 PM

Thanks, Jim.

The 2nd option says it's for PRGs so I assume it should have no relevance to method code in a form or class. I have it checked. I also have the 3rd & 4th items checked. BTW I also think that the assumption that any memvar starting with lower case l is always local ain't necessarily so but that's another discussion. :) I do realize that making some rule about how a local can be identified is necessary but perhaps it should apply to code that uses full Hungarian notation. Anyway, I digress...

I understand the theory. I'm questioning the implementation behavior. :)  I guess I'm not explaining clearly what's happening and what I'm expecting to see.

My expectation is that when global or local declarations are added, they are limited to the method being beautified. In the example I posted, there should be a global comment in the init and nothing at all in the command click. In my production form where I was trying this, I saw a similar issue with a local declaration. Methods that should not have anything added because there are no memvars in the code continued to get the local definition of the last method with a local memvar. At least that appears to be what I'm observing.

I've dummied up a quick test form to illustrate and will email to you shortly.

As for the missing gif, I pointed it out so the zip on VFPX could be refreshed but I appreciate you trying to send it to me. (Either you forgot to attach it or the VFPX board software thoughtfully stripped the attachment... :))

Coordinator
Apr 7, 2011 at 3:28 PM
Richard --
Layers of confusion here, I am afraid. See my interspersed comments.

On Thu, Apr 7, 2011 at 8:04 AM, rkaye <notifications@codeplex.com> wrote:

From: rkaye

Thanks, Jim.

The 2nd option says it's for PRGs so I assume it should have no relevance to method code in a form or class. I have it checked. I also have the 3rd & 4th items checked. BTW I also think that the assumption that any memvar starting with lower case l is always local ain't necessarily so but that's another discussion. :) I do realize that making some rule about how a local can be identified is necessary but perhaps it should apply to code that uses full Hungarian notation. Anyway, I digress...

The option I was referring to was the combobox, where you get to identify which variables to want to have localized. The overall assumption is that any variable beginning with lowercase 'l' should be, and the question is what to do with the rest of them. I believe you have checked the second item from the list. (That's the only one which creates a 'Global' comment). Regardless of the assumption, you have complete control of the actual locals created within the plug-in PRG, so you can modify it as you feel appropriate to handle Hungarian notation.
s1.png
The option that says 'In PRGs, create locals for ALL procuedures' is not intended to mean that it does not work on method code. Indeed it works on both method code and PRGs. The option exists so that when you are working on a PRG, you can indicate whether you want to work on the entire PRG, or just the current Procedure.

I understand the theory. I'm questioning the implementation behavior. :) I guess I'm not explaining clearly what's happening and what I'm expecting to see.

My expectation is that when global or local declarations are added, they are limited to the method being beautified. In the example I posted, there should be a global comment in the init and nothing at all in the command click. In my production form where I was trying this, I saw a similar issue with a local declaration. Methods that should not have anything added because there are no memvars in the code continued to get the local definition of the last method with a local memvar. At least that appears to be what I'm observing.

That is a bug and is not by design. It's just that nobody has pointed it out before.

I've dummied up a quick test form to illustrate and will email to you shortly.

As for the missing gif, I pointed it out so the zip on VFPX could be refreshed but I appreciate you trying to send it to me. (Either you forgot to attach it or the VFPX board software thoughtfully stripped the attachment... :))

I am working on version 7 now, and will correct it in that release.

Read the full discussion online.

To add a post to this discussion, reply to this email (VFPX@discussions.codeplex.com)

To start a new discussion for this project, email VFPX@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Jim Nelson
(805) 498-9195 (voice + fax)
(720) 837-3536 (cell)