Alternative PRG editor for VFP 9?

[dmusicant]

I've pretty much always used the editor furnished in Microsoft FoxPro in all versions (started with FoxPro for DOS 2.6, FPW 2.6, have used every version of VFP). I have an extensive procedural application that is based mostly on a single large PRG (PROCEDURE, with subroutines, mostly after the main code). Including extensive commented documentation within, it currently is 3825 lines. I would really like to dig deep into this, haven't for a while. The app is mostly fine (I use it daily) and does what I want, has some bugs I simply work around because I know how to (it's just for me, at least for now). However, I'd like to extend its capabilities, also consolidate some things. There are redundancies, certain things could be done better, and I'd like to fix bugs. As much as anything, I'd like to familiarize myself with what's going on in there... but all the above!

I just opened the PRG and I'm having trouble just navigating. If I'm browsing the Internet, I can just put two fingers on my laptop's mousepad and drag up or down and scroll. This doesn't work well in VFP 9's PRG editor. And keying the up or down arrow doesn't move the window unless the cursor is already at the top or bottom, respectively, it only moves the cursor to the next line of code.

At the moment, the editor's font is Courier New. I don't know if that's a good idea.

I heard quite a few times by VFP professionals that they don't use VFP's PRG editor. It appeared to be unpopular but I don't recall what they used instead. Can I get some suggestions? Thank you!

 

[TamarGranor]

If your giant PRG is actually a procedure file (that is, contains lots of other routines), I strongly recommend breaking it up into individual PRGs. I wrote about how to do that with code here:

http://www.tomorrowssolutionsllc.com/Articles/Splitting a Procedure File.PDF

Tamar

 

[Chris Miller]

Regarding keyboard usage pagedown/up scrolls pages right away.

But that aside, a good way to navigate a larger PRG file is by using document view, just try it. Besides have you ever used bookmarks and the feature to jump to next/previous bookmark? Or the tasks list and task shortcuts? The latter would be a nice way of building a to do list where clicking on a to do item you get directed to the point in the code, this isn't limited to one prg, the task list is global, so it's not even bound to just one project. You can add tasks from a line of code or you can create tasks in the task list and then may or may not associate that with a line of code the other way around. Doing it that way around the "contents" is yours and not just the code in the line number of a PRG or class method/event.

You are not limited to use it for tasks obviously, or associate it with a due date. The technical interesting feature for code navigation is just that you get transported to the code, even when it's not yet open.

Both things are adding to each other, the nice thing about document view is that its instantly populating a list while the task list is yours to build.

Chriss

 

[dmusicant]

Yes, Tamar, it's a procedure file. There are quite a few subroutines in it, tacked on after the main procedure comes to an end. It does call some code that's in the VFP path (i.e. not in the main procedure file), but by and large it doesn't do that. A lot of the subroutines are tiny, some fairly extensive but, of course, they exist just to support this one app.

Now, I did create a project for the app and created an .app file, have generated an .exe version too a few times, but inasmuch as it's just me using all this stuff, I just run the procedure. I can run it from the command prompt or from a front end screen that runs some of my other stuff too. I keep the code on my NAS, so any of my machines run it off that server. The data that serves the app is on the NAS as well.

I suppose I could just drop separate PRGs in my \programs folder to support it or create a separate folder to store them, which would be more tidy... the amount of code I have in my folders is daunting, although I don't usually go there and look for stuff. I have a table I keep (well, lots of tables) that help me keep track of things. I can search there and read memos I make that help me stay organized. All that is within the app, actually. It basically manages my data, in many ways, and different kinds of data, stored in DBFs and it utilizes some DBFs that are strictly metadata.

Chris, bookmarks! Hmm. Well, that's clearly different from breakpoints, I guess, which I don't use much. Is that documented in VFP? Ah, a quick search reveals this topic in Help: How to: Create Bookmarks and Task List shortcuts. That's news to me. There's a lot of stuff going on in VFP that I haven't ventured into. That includes Document View too, evidently.

This app isn't really object oriented. There's a screen for it and a couple of help screens (that I hardly ever bring up, they were kind of for other people originally, but can remind me of things, I have features in this thing that I've forgotten!). But that main screen was generated in FPW 2.6a. I can't modify that screen or see it's code without using a 32 bit machine, which I can do when required.

 

[dmusicant]

When did Microsoft implement bookmarks in VFP? I'm not seeing it in the index to The Hacker's Guide to VFP 6.0.

 

[Mike Lewis]

You've raised some interesting points here, and have received some good answers. Let me just try to add a few further points.

You said, "the editor's font is Courier New. I don't know if that's a good idea." If you don't like that font, you are free to choose another one for the editor window. Just right-click in the editor window and choose Properties. In the resulting dialogue, you will be able to change the font, and also the point size and several other options. (Although you can choose any font you like, monospaced fonts are generally recommended for viewing and editing program code.)

Regarding navigating a large PRG, the Document View window is definitely a big advantage. I have it open permanently, docked to the command window. That alone should speed up your editing considerably.

Bookmarks vs breakpoints. No, they are quite different. Bookmarks help you navigate the file, They make it especially easy to jump between far-apart bits of code when you are working on two or more routines at the same time. Breakpoints are to do with debugging. Although they are visible in the editor, their main use is at run time.

Regarding Tamar's suggestion of splitting a large procedure file into smaller PRGs. We have discussed this many times in the forum and elsewhere. Tamar has argued strongly for this approach, but others are less enthusiastic about it. There are pros and cons. I suggest you give it a try so that you can judge for yourself.

Turning to your main question, we had a discussion here a few weeks ago about using Notepad++ as an alternative editor (sorry, I can't find the relevant thread off hand). Again, there are pros and cons. Personally I think it is a terrific editor and I use it a lot. But not for VFP work - for the overriding reason that it is not integrated into the VFP environment. With the built-in editor, you can highlight a chunk of code and execute it straight away, without even saving the file. You can't do that with an external editor. Also in VFP, you can do dynamic Intellisense: declare a variable AS TYPE of a class, and have Intellisense recognise the properties and methods of that class. Those are just two examples of things that you would lose with an external editor.

Personally, I would stick with the built-in editor, but others will disagree. It will be good to hear other views.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dmusicant]

Thanks, Mike. To address your response (and Tamar's):

I was aware that I can easily change the font and size in the editor. I just thought I'd ask for suggestions. Your suggestion of sticking to monospaced fonts (which I believe courier is) is helpful. I guess I can stick with what I'm using, just adjust size. Courier doesn't bother me. I just thought I ought to ask for an opinion.

Document View, I don't know if I've ever even seen that. Thanks for the suggestion, I will check it out and have the feeling I'll be doing as you suggest and sticking with it!

Yes, I figured breakpoints are basically for debugging. I occasionally use them. I have Hentzenwerke's Debugging Visual FoxPro Applications and really should get into it. I use the Debugger, but am not great with it.

I read a bunch of Tamar's treatment that she linked, which was really cool of her, writing it, making it available and linking me to it here in this thread. Of course the monster procedure file that she was dealing with dwarfs mine. However, the techniques she explained still may be worth my using.

Tamar: I had the idea in reading your article that running a procedure from the Command Window will run the code and not the EXE if you add the ".prg" onto the command. I've had to do that many times to sort out getting the wrong code executed. I don't know if that speaks to the issue you were having there however it came to mind and I thought I'd mention it.

I suppose I should look into Notepad++, which I don't _recall_ hearing of before, but maybe I did(!). I have been using Metapad as my text editor for years, although rarely use it to look at Fox code. If you can find that thread on Notepad++, please provide it!

 

[Chris Miller]

dmusicant,

are you talking about the paragraph in "Splitting a Procedure File" that starts on page 15 and spans to the next page?

I think you got a right understanding, it has to do with caching of code (instead of data) that VFP also does, and that can be manually controlled by CLEAR in various variants, where you also find an entry point in understanding this procedure file cache. It usually works flawless without you noticing it's there, as always with such things. They only become visible when they don't work or cause an unexpected behavior.

Everyone's experience about running a PRG, finding an error, fixing it and then starting the fixed PRG is that the new code is executed. Well, see for yourself, an EXE doesn't even need to be involved:

MKDIR procedurecache
CD procedurecache

STRTOFILE("? '42'","theanswer.prg",.f.)
DO theanswer

SET SAFETY off
STRTOFILE("? 'FoxPro'","theanswer.prg",.f.)
SET SAFETY ON

DO theanswer
CLEAR PROGRAM theanswer
DO theanswer

And there's no bug that makes this unpredictable, a design that would invalidate anything in the cache with same name would just make this cache mechanism less effective.

The IDE usually has a good grip on this procedure cache (and classlib/class cache, though that's not relevant here), because usually you edit a PRG with it's editor and not by overwriting it, in that case VFP will finally save changes, compile with the save or at least invalidate the cached version it had.

So usually that cache is invisible to you, just works for the best and makes no problem.

Chriss

EDIT: Just wanted to add, that of course the STRTOFILE() that changes the prg after it was executed is also coming from VFP, even from the same session of VFP, but only going through the editor VFP realizes the need to reload the changed PRG and not just execute what's already in the memory. The same thing could easily happen, if you work on the same file from multiple IDE sessions and the case Tamar described meant the PRG that was already compiled in the EXE was cached and this cache entry then also is taken for the source file, so DO actually looks in memory first, if there is a cached procedure file of that name. It wouldn't matter if the EXE is called thequestion.exe, when you execute theanswer from within thequestion.exe that's giving VFP a cache entry for theanswer.prg (or the answer.fxp), not for thequestion.exe

 

[tomk3]

Hello,

I have used several editor, like Notepad++ or Multiedit (since clipper days),
but I still use the vfp9 editor because it is deeply integrated and loads fast.

It works fine on my notebook, the mousepad emulates a scrollwheel, maybe yours can be setup this way, too.

Just a hint :
And there are ready made "dark themes" if you like.

https://github.com/DanielNogales/VfpDarkTheme

https://www.foxite.com/archives/nftools-editor-dark-themes-0000461981.htm#

You may add thor for extra functions (and gofish for a much better search in the project)
For a good overview on thor, see here

http://www.tomorrowssolutionsllc.com/ConferenceSessions/Try Thors Terrific Tools.pdf

best regards
tom

 

[dmusicant]

My mousepad on this Lenovo Thinkpad P1 (version 3) does emulate a scroll wheel nicely in a browser (two fingers on the mousepad, drag up or down), and does so very smoothly. But in the VFP 9 PRG editor it doesn't work nicely. Nothing happens until position suddenly jumps about an inch... sometimes, the behavior is actually unpredictable. Sometimes it moves an inch, other times 1/2 inch, often it doesn't move at all. The effect is off-putting. Now, I have another almost identical laptop (version 1) and have no issue with scrolling, reason being I am using that laptop with an external mouse. The scroll wheel is satisfactory in that usage. I used to use an external mouse with this laptop, but ditched that when I got used to the mousepad. I suppose I can just stick with an external mouse when editing complex PRGs with this machine (unless I can find a workaround).

I found the Document View feature. There are 49 subroutines in there for the PRG!

Here's a random sample. This function converts a VFP free table to a FoxPro 2.6 table. I created this so that I can run the program in FoxPro 2.6 and not get errors on VFP formatted tables:

************************************************** * *
Procedure _26tbl
Parameter tc_tblname, tcPath
* This function converts a VFP free table to a FoxPro 2.x table
Private wassel,wassafe,malias,ll_wasused,wasdef
If Type('tc_tblname')='L' && This is the assumption, that if no table name is passed, you are running it on the table
** open in the current work area.
tc_tblname=Alias()
Endif
If !'.'$tc_tblname
tc_tblname=tc_tblname+'.dbf'
Endif
ll_wasused=.F.
nm=tc_tblname
malias=Substr(nm,1,At('.',nm)-1)
If Used(malias)
ll_wasused=.T.
Use In (malias)
Endif
wassel=Select()
wasdef=Full(Set('DEFAULT'))
If Type('tcPath')='C'
Set Defa To (tcPath)
Endif
Use &nm Excl In 0
Sele (malias)
Copy To tempfile With Cdx
Use tempfile
wassafe=Set('safety')
Set Safety Off
Erase &nm
nmcdx=Substr(nm,1,At('.',nm)-1)+'.cdx'
Erase &nmcdx
Copy To &nm Type Fox2x With Cdx
If !ll_wasused
Use
Endif
If Used('tempfile')
Use In tempfile
Endif
Erase tempfile.Dbf
Erase tempfile.Cdx
Erase tempfile.fpt
Sele (wassel)
Set Safety &wassafe
Set Defa To (wasdef)
Return && _26tbl
****************************************************