# 4.8.10 Release Notes

4.8 Unix

Fix problem with "-pq"/filename attempting to execute filename, rather

than output to it.

Native95

Fix problem of occassionally missing release of Alt when CapsLock down,

causing Windows CapsLock bug workaround to be disabled.

Native95

Fix problem when pressing shift-numpad key twice in a row would act as

a Break.

All

Fix @FN length problem, where it was truncated to 10 characters in

some places in filePro.

All

Fix problem with SQRT(0) returning "/D0". Now returns "0" as it should.

All

Fix ddir problem emptying indexes when nodesize > 1K.

All

Fix fuzzy browse lookup problem when scanning on associated field,

where first instance would always be used.

DOS/Native95 Network

EXPORT ASCII -A truncated file on network version.

All

If filePro cannot read the full lockfile, an error is now generated.

All

DECLARE will now correctly give a syntax error if you try to declare

a variable that starts with a digit.

All

If an invalid edit name was given to DOEDIT(), the function returned

garbage. It will now return a null field.

All

If an error occurs in automatic processing (one that would normally

cause the "A system/filepro error has occurred" message to appear)

while in add records mode, no error is reported, and a new record

is added. (If this error occurs repeatedly, you will be stuck in

an infinite loop.) Note that the error must be in automatic and

you must be in add records mode.

Native95

Under certain conditions, Windows will return ERROR_WRITE_FAULT

or ERROR_IO_DEVICE, rather than ERROR_NOT_READY, for a printer-

not-ready condition. These are now trapped as a not-ready error,

rather than reporting "error -1"

If you continue to get "error -1" errors on printing, you can set

PFNTPRTERR=ON, and filePro will display the internal Windows error

number, which we can use to determine the cause.

Unix

If PFREADONLY=ON, "invalid argument" errors could occur if you access

a 4.5-style automatic index.

Unix

On some systems, ASC() would return negative numbers for characters

greater than ASCII 127. (Specifically, it would return the proper

value, minus 256.)

All

If you have a getnext loop, and within that loop you have another

lookup to the same file, and are posting new records (or changing

existing records' index key) such that the new index key value is

in close proximity to the current getnext-loop index key, it is

possible for the getnext loop to malfunction. (Skip records, or

duplicate records.)

Unix

If a help file was in DOS format (ie: includes "^M" for end-of-line)

then filePro would freeze when reading that help file.

All

If PFCHECKLOCK=ON, the error is now reported only once per lookup,

rather than on every assignment.

All

Dxmaint would display demand index dates after 12/31/99 as "mm/dd/100".

Native95

Added ability to use the Windows spooler:

Spooling for native windows filePro

Windows apparently doesn't spool print jobs sent by native windows console

applications to local printer ports, the way that it does for MS-DOS programs

that do the same thing. (That is, open "lpt1" as a file and write to it.)

We have added the necessary code to the native windows version of filePro

to use the Windows printer routines (ie: OpenPrinter, StartDocPrinter, etc.)

which do respect the Windows spooler. However, the spooler is also limited

to those printers defined in the printer control panel. Therefore, we have

made it a requirement that, in order to use the Windows spooler, you must

prefix the filePro destination with "win:", as in "win:lpt1:". The rest

of the destination must be the exact port name or printer name as you have

defined it to Windows. So, if you have a printer attached to LPT1 that is

named "HP DeskJet 870Cse", you would use either:

win:lpt1:

or win:HP DeskJet 870Cse

If you have a network printer "\\server\printer" that is captured to LPT2,

called "Bob's printer", and the Windows destination is "\\server\printer"

then you would use either:

win:\\server\printer

or win:Bob's printer

You could not use "win:lpt2:" as "lpt2" is not the destination that Windows

knows the printer by. (Though you could use "lpt2" without the "win:" and

go directly to that port without the spooler.)

Remember: You can only use the exact port name or printer name that Windows

uses. Anything else will result in a "the parameter is incorrect" error when

filePro tries to open the printer.