How do you maximize productivity when writing filepro code in a 24x80?

[Craig Tooker]

On 08/26/16 02:01, Stanley - stanlyn.com via Filepro-list wrote:
> Hi,
>
snip...
>
>
> Just wondering how I can interact with filepro's 24x80 fixed screen
> THE QUESTION IS.  How are you doing developing in filepro?  I'm sure most of
> you are developing on multi large screen monitors with each running in 1920
> mode.  I'm just trying to be more productive in the filepro ide and
> struggling is an understatement.

I've written an intermediate translator that allows me to program 
filePro code in my version of the language and translate that back and 
forth to the PRC ASCII files.

When I want to edit a PRC file I use:
prcget dbname [-f] prcname [-y autoname] [localname]

Where, if specified, "localname" is a file path/name that will be 
created that contains the translated code (I use a file extension 
.fpprc).  Without "localname" it just creates a temp file and runs "vim" 
on that file.

My translator creates files like:
' FPPRC=1.1, Table=input.fpprc, FP=input.prc, Date=20160826153000
'
errorbox "Trivial sample code; top of table"
if (ix = "")
{
	errorbox "calling init"
	gosub init
}
else
{
	errorbox "init already called"
}
end
event @wlf1
{
	if (1 = "")
	{
		screen @SN,1
	}
	end
}
sub init
{
	ix(1,yesno,g)="Y"
	return
}

Which as you can see creates a wrapper around filePro language code, 
dealing with the PRC file format and turns it into a language that can 
be dealt with using standard source control tools.

It also allows me to create templates of filePro code for language 
elements that don't exist in filePro (such as the "else" clause above).

When I use:
prcput dbname -f prcname [-y autoname] localname

It translates the ".fpprc" localname file into a legal filePro PRC file 
and puts it back into the correct folder under the database.  It makes 
lots of changes to the code as it translates it and uses many generated 
declares, labels and remarks to keep it all straight. It also creates 
the TOK file on the fly.

Two problems:
1. The generated PRC file is *ugly* but runs fine. You would not want to 
maintain that generated code manually without these scripts.

2. When I do edit the PRC file directly in filePro, I sometimes forget 
to bring the (now modified) PRC file back out again (with "prcget") into 
my source tree. I then edit the version in my source tree and then put 
it back. That of course, loses the changes I made directly. If I always 
use prcget before editing it is not a problem - but...

The syntax I have developed works great for me (a 'C' programmer), but 
obviates the "simplicity" of the filePro language. For some that would 
be a problem. For me, the frustrations of the limitations in the filePro 
language dictated my creation of this translator. That is all very 
subjective. It has allowed me to add elements like better loop 
constructs and better if, then, else and case branching. I also added an 
"include" directive that allows me to create standard libraries of code 
that are translated into the PRC file.

It also future proofs me if filePro maintenance ceases.  All I need to 
do then is write a translator to move my code base to a different DB 
engine (commercial or in-house) and my investment is not lost.

Fairly simple to do when I wrote all this fifteen years ago and it makes 
my filePro life much easier. It also means I can use any editor or 
screen size (for editing) that I would like.

Craig

>
>
>
> Thanks,
>
> Stanley
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20160826/0677a6b8/attachment.html>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>

-- 
Craig Tooker
CWT Software
Craig at CWTSoftware.com | Tel: 614-776-3371 | Cel: 216-210-2890