(All) #966
If you have a lookup file with memo fields, and do a COPY to that lookup, the memos won't be copied correctly.
(All) #963
If the cursor is on the last line of a wordwrapped line of text, and is on the first line within the memo editor window, and the rest of the window is filled with additional text, then placing the cursor at the end of the text on that line and backspacing such that the now-shorter text would re-wordwrap to take less lines, taking the cursor to the text which has been re-wrapped to the previous line (ie: the one above the top of the window), can cause filePro to crash.
(All) #967
In the memo editor, using the up and down arrows, if the cursor is in a column on the source line beyond the last column of the destination row, the cursor may be placed in the wrong location.
(All) #949
The 2-digit-year system date fields resolved without an EOFmarker in dscreen/dmoedef.
(All) #957
LISTBOX() would expand embedded TAB characters within items.
(All) #958
If you are on the last line of text in a memo, and that line wraps, and the end of that line (ie: the end of the memo itself) is visible as the last line in the memo window, and you start deleting text on that line such that the wordwrap now takes up less lines (ie: the word on the last line gets "pulled" up to the previous line), then filePro can crash.
(All) #960
The default value for PFLISTSLASH has been changed from ON to OFF.
(Linux) #940
Using LOCKED() in rclerk/rreport on Linux could crash filePro.
(All) #941
fPSQL could crash if the query required 10K of output per record. (Default increased to 100K, and it now properly reports error if exceeded.)
(ODBC) #943
Define files fails on an ODBC data source when the table name has embedded spaces.
(All) #947
If you have a dummy field which has not been given a length/type in processing, and place it on a screen, and then have a popup screen over that field, and when the popup isn't active (ie: after a POPUP UPDATE, but before a CLEARP, do a SHOW "@...", the contents of that dummy field will bleed through to the popup.
(All) #951
If you have a fuzzy browse lookup with "show=pkeep", filePro would crash upon re-executing the lookup.
(All) #954
If you have any pending PUSHKEYed keystrokes, the filePro processing debugger didn't update the screen as you stepped through processing.
(All) #955
-SX flag to *report did not load the selection set.
(All) #939
PFNUMIXBUILD was incorrectly documented as allowing up to 128000. The real maximum is 32767, which is now enforced by filePro. (Setting it higher than the maximum value will result in using the maximum.)
(Linux)
filePro had problems with the shared libtermcap on 64-bit Linux platforms, so we now statically link to our own termcap library.
(All) #924
PFNODFMSG=OFF turns off ddefine's "PFNODF=ON" notice. (Default: ON)
(Windows)
pmaint now has an F6 option to display a list of system-defined printers while in the "destination" field of the printer config screen.
(All) #927
Fixed a problem with node_addr and DKNF errors on indexes which are larger than 65536 blocks in size.
(All) #938
MEMO handle EXPORT filename APPEND
BLOB handle EXPORT filename APPEND
Would crash at runtime.
(All) #931
FIELDNAME/LEN/EDIT/VAL didn't take an expression for the field number.
(ODBC) #932
dreport was unable to post new records to some high-level ODBC data sources.
(*nix) #933
If you were to have a variable/array/lookup/etc called "USER", then the parser would allow some invalid syntax, where part of an expression was missing, such as "aa = bb +".
(Linux) #934
There are two distinct, and incompatible, pty methods on different Linux boxes. fpdaemon now includes both methods in a single binary, and determines at runtime which method to use.
(All) #935
dxmaint would show "not available" on indexes that were in use, but it would still let you rebuild them.
(All) #936
MEMO...SHOW now accepts the NOWRAP flag, just as MEMO...EDIT does.
(Linux) #926
fpcopy would fail with "cannot create new data file" on some Linux systems.
(All) #779
Executing a multi-line DIM would cause line 1 of the processing table to be executed for each of the continuation lines.
(All) #783
A non-dash lookup to the main file may clear non-",g" DECLAREd variables. (See also #785.)
(All) #785
If you have DECLAREd GLOBAL variables in the automatic and/or the input/output table, and then CALL another table which DECLAREs addtional GLOBAL variables, such that the total number of such variables crosses a multiple-of-32 boundary, and then from within the main input/output table execute a non-dash lookup to the main file, filePro may crash. (See also #783.)
(All)
Add PFCLOSEPENDWARNING=OFF to disable the warning if you attempt to close an HTML tag when it was not open.
(All) #801
Swapped the memo editor extended functions T and I from:
T - Toggle insert
I - Insert time
to
I - Toggle insert
T - Insert time
Use PFMEMOEDITOLDKEYS=ON to restore the old keys.
(All) #803
Increase the compiled tok code limit from 128K to 2MB.
(All) #808
When passing both "-XIn" and "-D" flags to *clerk, the "Press DEL" prompt from the index box wasn't cleared.
(fPSQL) #817
"SET QUALIFIER" was ignored in the network version of fPSQL.
(Solaris/AIX) #822
"GOSUB (expr) OF ..." could crash the prc compiler on Solaris and AIX platforms with a SEGV or bus error.
(Solaris/AIX) #823
A DKNF error could cause a SEGV or bus error on Solaris and AIX platforms.
(*nix) #827
The MSB of the color attribute bit originally meant "blink" on MS-DOS systems. Windows changed the meaning to "high-intensity background". The *nix version of filePro still used this for "blink".
Moving color screens from Windows to *nix would cause a different appearance between Windows and *nix if this bit was used anywhere.
The *nix version of filePro now ignores this bit by default, as ANSI does not define a "high-intensity background" escape sequence.
PFMSBBLINK=ON will restore the old behavior of MSB meaning "blink".
(Quikstart) #784
If you have an array aliased to dummy fields and use "CLEAR arrayname", and run in read-only mode, filePro would report an "attempt to modify read-only file" warning, even though no real fields were modified.
(All) #707
Some old output formats would cause dmoedef to crash.
(fileProGI) #720
ddir/dprodir did not prompt to confirm deletions under fileProGI.
(All) #763
Using a DECLARE LOCAL variable as an array subscript could give a false "subscript out of range" error in *report.
(fPSQL) #769
When running a query from the command line, and sending the output to a file (via SET OUTPUT), if no records are selected, the "no output generated" message box is no longer displayed.
(All) #777
A stray graphics character was printed at the very end of memos.
(Cosmetic) #780
The spacing of prompts in dscreen's F8/options screen was not consistent.
(All) #781
dxmaint did not allow indexes to be built on the 4-digit-year system date fields.
(All) #786
FORM now strips trailing blanks from the format name, eliminating the need to use FORM name{""
(All) #790
Pressing F8/Options in dscreen would cause a screen's password to be removed.
(All) #791
When placing a memo on a subtotal/grand total line, the memo's height would be shortened.
(ODBC) #794
Due to a bug in Microsoft's runtime libraries, pmaint would crash if the .prt file was in Unix format (LF line endings) rather than Windows format (CRLF line endings).
(All) #809
The filePro debugger would read PUSHKEYed keystrokes.
(All) #813
A lookup back to the main file on an index built on a key length of a multiple of 32 bytes could crash filePro. ("Debug error DAMAGE" on Windows, and SEGV on *nix.)
(All) #841
A "WRITE lookupname" where "lookupname" has been closed can cause filePro to crash.
(fileProGI) #829
After executing the configuration editor in ddir, the display was corrupted.
(All) #833
A SHOWCTR or SHOWTOCOL executed after a SHOW (w/o row and column) would be displayed centered on line 23 after doing a browse lookup.
(All) #854
LISTBOX and FIELD* functions would pass syntax check (but fail at runtime) if the close parenthesis was missing.
(All) #856
Marking text in the memo editor would sometimes hightlight the wrong part of the memo.
(All) #857
An automatic index built on multiple associated fields could cause the wrong record to be read on lookups or index-by searches.
(All) #859
F7 in the memo editor when on the last word-wrapped line of a line of text would place the cursor on the last character in the text, rather than on the end-of-line marker.
(All) #867
Index scan (PFIXS=ON, -j) would not correctly handle indexes with descending sorts on scans other than "EQ". (It would only find matching records.)
(All) #874
Hardcopies from pmaint would print 1 more line per page than defined for the printer.
(All) #879
If you do multiple cross-reference hardcopies in *cabe in a single session, without printing the prc itself, the page number is not reset between printouts.
(All) #880
The cross-reference listing in *cabe would leave off the field numbers in lookup files if the field number was greater than the number of fields in the main file. (For example, "lookupfile[20]" would print wth a blank number if there were less than 20 fields in the main file.)
(All) #704
fPCopy couldn't copy ODBC files.
(All) #865
A selection set with memo_field gt "" a a condition would select all records, rather than just those with the memo not blank.
(All) #866
If you left the menu item "title" entry blank, the item was not drawn, though you could still highlight it.
(All) #871
If you chose to xfer to a file by selecting the menu choice within xfer, rather than the "-lf" flag, it was possible to crash xfer if the record size was very large.
(All) #881
If you brought up the memo editor in READONLY mode, the prompts still included those options which would not be applicable.
(All) #882
IMPORT/EXPORT files were closed before @DONE was executed.
(All) #884
Browse lookups with "show=pkeep" would not retain the cursor position if the key length were zero.
(All ODBC) #793
Under MS-SQL ODBC server, in some conditions, *report and dxmaint would fail with an "invalid descriptor index" error.
(All) #847
Running *report with the "-ro" flag could cause a "file table full" error on some platforms.
(All) #885
Calling DLEN() with a string longer than 256 characters and of "just the right length", or SHOWTOCOL with "just the right length" could crash filePro. ("Just the right length" being dependant on the particular platform.)
(ODBC) #887
There is an undoumented limit to Microsoft's MFC ODBC library which restricts you to 256 columns in any given view.
(*nix fPSQL) #889
fPSQL's help engine didn't handle Windows-formatted text files on *nix systems.
(All) #892
If you modify a real field in automatic processing in *report, and an automatic index is built on that field, the index may not be properly updated.
(All) #896
DIM of an array name which started with a number did not give a syntax error.
(ODBC) #897
Given the right combination of data source, ID field type, and PFODBCCOMMITTYPE setting could cause dxmaint and *report to improperly sort the file.
(Windows) #904
Under Windows, dxmaint used to show a date of "00/00/00" for demand indexes.
(All) #909
If you have a browse lookup with "-m" on a multi-key index, and pass a blank key, no records will be matched unless the entire key in the lookup file is all blank, rather than just the key specified in the lookup.
Changes to filePro behavior:
A null key passed to a browse lookup now means "find the lowest key", rather than "find an all blank key". If you specify "mlen=" on a browse lookup, and do not nave PFBRWM=ON to make trailing blanks significant, filePro will not make the key shorter than the specified mlen length. (For example, a key of 8 spaces with "mlen=4" will result in a key of 4 spaces.)
(All) #718
With PFIXS=ON, filePro scans could fail with an index built in descending order.
(ODBC) #799
ddefine would allow you to build default (empty) indexes on ODBC data sources that had data in them.
(All) #802
If you executed a CHAIN command from within an event which was triggered while updating a screen from a SCREEN command within another event, then when you save the original SCREEN, filePro would attempt to continue from the original SCREEN command, which is no longer there due to the CHAIN.
For example:
@UPDATE issues a SCREEN command. While updating the screen, an @WLF event is triggered. Within the @WLF, a CHAIN is executed. You continue updating the original screen, and press SAVE. At this point, filePro attempted to continue from the SCREEN statement above.
(Windows) #818
The Windows version of filePro used to permit PFDIR to include a drive letter, which should not have been permitted. filePro no longer allows this. Should you absolutely need to have a drive letter in PFDIR, then you can set "PFDSK=;", and "trick" filePro into "working" again.
(*nix) #890
setperms and fp.list updated to not touch files placed in the filepro/filename directory which are not part of filePro.
(All) #898
The memo editor didn't have a way to cancel "mark" mode without actually doing a cut or copy. You can now cancel "mark" mode with "X".
(All) #899
Pressing up-arrow from a field on the first row on a screen without a cursor path would not move the cursor to another field.
(Windows) #903
If the last character on a screen was green-on-blue (attribute 0x1A), the screen format would get the last byte truncated, making the file invalid.
(All) #905
ddir/dprodir would give an error if you tried to delete the data from a non-filePro file that pointed to a non-existent file.
(Windows fPSQL) #906
If an error occurred and fPSQL displayed a filename in an errorbox, and that filename included backslashes (ie: "\filepro\filename" as opposed to "/filepro/filename"), the errorbox would be displayed improperly.
(All) #907
The index selection box in dxmaint would not respond to a keypress if that keypress corresponded to the currently-highlighted index.
(All) #911
dclerk would crash if you attempted to display an old-style screen which had been corrupted.
(All) #914
If you have the same variable DECLAREd more than one in the prc file, then F6/D to display dummy fields and variable would show none.
(All) #917
If you have an uncast dummy field which has never had a value assigned to it, filePro could crash if you try to SHOW that field.
(All) #921
In dscreen and dmoedef, importing a text file that didn't end in a newline would not import the last line of the file.
(All) #922
Browsing on an inde built on an associated field would show the first instance regardless of the correct instance, for the top record on the screen after pressing "R" to reset the browse to the beginning.
(All) #923
A browse lookup on an index built on an associated field would show the first instance regardless of the correct instance, for the first record shown in the browse window.
===================================
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.