Tuesday, June 25, 2019

The FoxShow 86

Listen to Tamar Granor discuss women in tech, different ways of sharing information, and how to go from wallflower to presenter on The FoxShow 86.

Monday, June 24, 2019

Southwest Fox 2019 Super-Saver Deadline Approaches

Registration for Southwest Fox 2019 has been open for a few weeks and there’s less than a week until the Super-Saver Registration deadline. If you register before the end of June, you save $125 and we’ll throw in a pre-conference session worth $99. Not only that, but you’ll be entered in the drawings for a scholarship that will reduce your cost even more and a license of Stonefield Query SDK, a $2,500 value. Check out the speakers and topics on the conference website.

Please beat the rush so we still have some fingernails left when July begins! No need to wait, we won’t charge your card or cash your check until the middle of July!

Wednesday, June 19, 2019

The FoxShow 85

Join us on The FoxShow 85 for a discussion with Rick Schummer, one of the organizers of Southwest Fox, as we learn where he started, what and how he's learned to get to where he is, and why conferences will make him say "wow - how can I use that?"

The FoxShow 84

On The FoxShow 84, Andrew MacNeill and I talk about my start in the computer industry from Commodore PET and how much FoxPro development I do today. I'm also excited about the Southwest Fox conference and what I've learned from past conferences, and the real reasons people should attend (hint, it's not just the sessions).

Thursday, June 06, 2019

Integrating Project Explorer with Search Utilities

I’ve been using Project Explorer as a replacement for the VFP Project Manager for a couple of years now. However, I recently ran into a gotcha that I need to handle better. Here’s the story.

If you have it configured to do so (and I do), Project Explorer automatically generates the text equivalent of a binary file such as a form or class using whatever conversion tool you’ve specified (I use FoxBin2Prg) when you’re finished editing the item. I rely on this heavily: every day, I’m modifying some class or another, knowing the VC2 file is automatically created so I don’t have to do it manually. Since our source control repository contains only the text equivalents, not the binary files, this is very important.

The build process for Stonefield Query Enterprise Studio, the developer tool for the web version of Stonefield Query, runs on a build server. It pulls from the remote repository, uses FoxBin2PRG to generate binary files from the text equivalents, builds an from the PJX file, and uses Inno Setup to generate a setup executable.

Recently, one of our developers discovered a bug in Studio. It sounded like something I had just fixed, so I couldn’t reproduce it in my copy, but could in the version generated from the build server. I checked the VCX/VCT files from the build server and sure enough, the class had the unfixed bug. I checked my copy: it had the bug fix. Then I looked at the VC2 file on my machine and saw that the bug was still there. But how could that be?

Then I remember how I’d fixed the bug. I opened my project search utility (yes, I’m aware of GoFish and even use it from time to time, but my utility does 99% of what I need and is way faster), searched for some text, double-clicked the class it found, fixed the bug, and closed the Class Designer. The problem is that since even though Project Explorer was open, it wasn’t asked to open the class, so it didn’t know the class had been changed and didn’t call FoxBin2PRG to generate the VC2 file, so the bug still existed in that file and in our repository.

Of course, it was easy to resolve the problem: generate the VC2 file for the class, commit the change, push to the repository, and run the build process again. But I wanted to make sure this didn’t happen again, so I added a new method to Project Explorer: EditFile. It has the same syntax as EDITSOURCE, but when you close the editor, Project Explorer automatically calls FoxBin2PRG if the file is a binary just like it does if you click the Edit button in Project Explorer. Then I edited my project search utility:

if type('_screen.oProjectExplorers') = 'O' and _screen.oProjectExplorers.Count > 0
    loPE = _screen.oProjectExplorers[1]
endif type('_screen.oProjectExplorers') = 'O' ...
do case
* Other code here.
    case FILES.TYPE = FILETYPE_FORM and vartype(loPE) = 'O'
        loPE.EditFile(lcFileName, lnLineNo, justfname(lcFileName), lcMethod)
    case FILES.TYPE = FILETYPE_FORM
        editsource(lcFileName, lnLineNo, justfname(lcFileName), lcMethod)
    case vartype(loPE) = 'O'
        loPE.EditFile(lcFileName, lnLineNo, lcClass, lcMethod)
    otherwise
        editsource(lcFileName, lnLineNo, lcClass, lcMethod)
endcase

So, when I tell my utility to edit a file containing the search text, it either uses EDITSOURCE if Project Explorer isn’t open or it calls Project Explorer’s EditFile method if it is. Problem solved. The latest version of Project Explorer on GitHub has this change.

I haven’t updated GoFish or Code References but posted an issue with both projects in case the developers or someone want to add support for Project Explorer.