Wiki Home

VFP Undocumented Bugs

Namespace: WIN_COM_API
Here is a place to describe bugs that are not listed in the Visual FoxPro 6 Official Bug List.

If an undocumented bug is listed here, is it still undocumented? many questions, grasshopper...

INLIST() is permissive

[VFP6] According to the documentation, INLIST(candidate_expr, expr1, expr2, ...) suggests that it tests to see if the first expression is in the list that follows it. Example:

INLIST("A", "A", "B", "C") = .T.
INLIST("D", "A", "B", "C") = .F.


INLIST("AA", "A", "B", "C") = .T.

This seems to run counter to the documentation, which suggests that it looks for the first expression in the list, whereas it appears to be doing the reverse. Plays havoc with any serious attempt at pattern-matching, since some strings will match erroneously (example, doing UK postcode matching: INLIST("A99AA","A9", "AA9", "A99", "AA99", "A9A", "AA9A") = .T.

I disagree that this is a bug: it's an effect of how VFP compares strings. With SET EXACT OFF, INLIST("AA", "A", "B", "C") = .T. but with SET EXACT ON, INLIST("AA", "A", "B", "C") = .F. The same is true if you simply use ? "AA" = "A". -- Doug Hennig

In which case, shouldn't the default be SET EXACT ON? Any comparison which believes "AA" = "A" is fundamentally broken, especially given there are other perfectly usable methods of comparing only the beginning of a string. Unless, of course, "A" = "0". :-)

The nice thing is that this is completely under your control. SET EXACT the way you need it to behave. -- Doug Hennig

Actually, the confusion comes from VFP's overloaded = operator. Like C++, VFP's operator for "exactly equal" is ==. In VFP, C++, and other languages, the = operator is a value assignment operator. But in VFP, the = operator has another specialized meaning for string comparison; that is, is each character in the string on the left side the same as the character in the corresponding position on the right side? To make it even more fun, for numeric or logical values, the = operator means "exactly equals". So these are really completely different operators, as determined by what surrounds them. The concept comes from C++ (the source code language for VFP), where the function of operators is user-defined and the same symbols are frequently overloaded with several functions based on what comes before and after them. -- Ken Dibble

Given that the same comparison can be done with LEFT("AA",1)=="A", perhaps SET EXACT OFF is one for Visual FoxPro Useless Features instead? I can't think of a suitable use that justifies its interference with the otherwise well-understood meanings of "=".

This is definitely not a useless feature -- I use it extensively. However, it is something you need to be aware of when doing any string comparisons. -- Doug Hennig

So what would be an actual use case for it?

In my opinion, the most common use of the partial-match-equals is for dealing with VFP's CHAR-type fields. By using the partial match, seeks land close without getting NOT FOUND(), and you don't have to TRIM() to compare [IF TABLENAME.NAME='john'] when [TABLENAME.NAME=='john ']
Now that VARCHAR fields don't pad every field with spaces, I admit that this isn't as useful as it once was. I also admit that I have often wished that INLIST always used a == compare instead of =, or that there were an alternate function like INLIST_EXACT(). Of course you can implement it yourself by wrapping an INLIST call that saves and restores SET EXACT, but the UDF is then significantly slower. I believe this "inexact equals" was originally justified by the same thought process that allows "john"=="John", or even "jöhn"=="John" when SET COLLATE has certain values. -- wgcs
CTRL+W Presses Buttons

Create a form with a command button on it. Run the form. Press CTRL+W on the keyboard. The button is clicked.

If you put a textbox on the form and set its TabIndex to 1, and make the button's TabIndex 2 and set its Default to .T., then when you press CTRL+W, the default button is clicked.

VFP Help (VFP 7--but the bug exists, and remains unacknowledged, in VFP 9 SP 1) says CTRL+W "Closes current text window or dialog box and saves changes." Well, it does that in some VFP IDE windows. However, in a user-defined form, it closes nothing and saves nothing. It clicks buttons, without warning, and with at least annoying, and potentially disastrous, consequences for a user who expects something else.

This was reported to the VFP team, whose response was essentially, "It's not a bug because it's by design that CTRL+W closes windows and saves their contents." Some other developers didn't want it acknowledged as a bug or fixed because, as they said, they found it useful to have CTRL+W close windows and save data. (By the way; CTRL+W to close windows is, while rather common, not a Windows standard. CTRL+F4 and ALT+F4 are the Windows standard keystrokes to close windows.)

I find these responses incomprehensible.

Once again, in a user-defined form, CTRL+W closes nothing and saves nothing. It clicks buttons. It's a bug, and a bad one. -- Ken Dibble

i found two ways to get rid of your problem:
1) Just put the following lines in the keypress event in your form-baseclass:

IF nKeyCode = 23 AND nShiftAltCtrl = 2 THEN

2) Put this code in your forms activate (or anywhere else where you can be sure it is not being overwritten by popkey etc...)

have fun,
Alexander Lagler

Thanks. I knew there were work-arounds. The Key Press() option is problematic when one's form baseclass has code in that method, and subclasses have additional code in that method. The ON KEY LABEL option is a better one in this particular case, where we never want anything to happen for that key combination. But the fact that there are workarounds doesn't make this "my problem"; it's still a bug. :-) -- Ken Dibble
VFP 9: TRY..CATCH does not properly "Catch to" a private variable. See more here: TryCatch (reported to MS) - wgcs
Pre-script: the link at the top of this topic to the VFP official bug list seems to be broken, so I'm not sure if the topic has been dealt with. My searches have found nothing.

Visible setting in grids propogates to all columns, and is applied at design-time.

Applies to VFP 8 and VFP 9

When editing a form, if a grid has its visible property set .F. all the columns also have their visible property also set .f., and the columns promptly disappear. This makes column properties very hard to edit, and column layout editing (eg: changing column widths visually) impossible.

Two things seem to be happening:
  1. Whenever the setting of visible for the whole grid is changed, the new value is propogated to all the columns of the grid.
    • This occurs at both design-time and run-time
    • At run time this means, in a grid that starts out hidden, columns that you want to stay hidden have to have their individual visible property set in code after the grid setting is changed. There is not point in setting column visibilities at design-time, or before the grid is made visible, because the column properties are over-ridden when the whole-grid property is changed.
  2. The visible property of columns effects design-time appearance
    • I suppose there could be a good reason for this, as the grid columns appear as they would at runtime. However no other control goes invisible (as far as I know) in the designer when its visible property is set to .F.
This ends up with, for grids that are initially invisible at run time (a) they are very difficult to edit in the form designer, and (b) individual column visibility can only be controlled in code, and then only once the parent grid has been made visible.

The changes that would seem to be needed are:
Jeff Green

This was corrected by Doug Hennig in VFP 8 or 9 - William Fields

When you make modifications to a DBC's R.I. rules, any existing table trigger expression that includes an "OR" condition will be changed to an "AND". For example, on one of our tables, the following expression is in the delete trigger:


This allows us to override the R.I. rule if needed for administrative purposes (don't worry, there's a good reason for this). But, if modifications are made to the R.I. rules via the R.I. builder, the "OR" in the above expression is changed to "AND" when the R.I. code is generated. This applies even if the R.I. rule mod has nothing to do with the table that has the "OR" trigger expression.


Run code below and observe output to _SCREEN




RI Builder leave the DELETE trigger alone so we get:


*------- START CODE
   (SalesID c(6) PRIMARY KEY, ;
   SaleName C(20))

   (SalesID c(6), ;
   CustId i PRIMARY KEY, ;
   CustName c(20) UNIQUE,   ;
   SalesBranch c(3), ;


      AS __ri_delete_badrisalesman() .OR.(IIF(TYPE("g_lSkipDeleteRI")="L",g_lSkipDeleteRI,.F.))


USE BadRISalesman
AFIELDS(laInfo, 'BadRISalesman')
? laInfo[15]
USE IN SELECT('BadRISalesman')


USE BadRISalesman
AFIELDS(laInfo, 'BadRISalesman')
? laInfo[15]
*------- END CODE

- William Fields

Popups cascade off the screen in VFP7/8/9

In VFP6 when a popup cascaded it cascaded on top of the original popup - this could be confusing, but at least it didn't cascade off the screen.
In VFP8 popups no longer cascade on top of one another, but they can cascade off the screen.

Define Bar 1 of fred prompt 'Item1'+Space(200)+'.'
On Bar 1 of fred ACTIVATE POPUP fred2
Define Popup fred2 RELATIVE SHORTCUT
Define Bar 1 of fred2 prompt 'Item1'+Space(200)+'.'

-- Rhodri C Evans
Shortcut menus fail to show all entries when they are taller than the screen

If a shortcut menu (context-sensitive menu) is taller than the screen, it should scroll and, in fact, it tries to, however it doesn't work. I have a very tall menu that displays fine at my resolution of 1280 x 1024, but at my client's lower resolution of 1024 x 768, it will not fit. He sees scroll arrows at the top and bottom of the menu, but when he tries to scroll down it scrolls one or two lines and then stops, even though there are 10 or so entries below where it stops. Then if he goes back and scrolls up, the scroll arrows disappear completely and he can't scroll at all. The fix for me will be to shorten this menu (the user can add entries to the menu to set filters on a table and they've added quite a few), but this does seem to be a bug (I'm using VFP 9). A similar bug was reported in the MS KB article below and they claim to have fixed it way back in VFP 6 SP3, but that claim doesn't seem to be correct (or they broke it again or the bug, though similar, is not the same).;en-us;221643

Russell Campbell
VFP7, VFP8, and VFP9 Beta are all afflicted by a bug that causes OLE controls to not be visible when .Visible is set to .T. and any parent container is not visible.

Once the parent becomes visible, the ole control should become visible as well, but it doesn't. See ?VFP Ole Control Visible Bug

This has been reported to Microsoft. -- Peter Crabtree
The VFP8 combobox displays two ampersands (&&) when there is supposed to be just one. For example, when I populate my combobox, either using an array or value, and one of the elements is "S&P", it displays as "S&&P". Annoying. Didn't happen in VFP7. Anyone else run into this? So far I haven't found a fix. If I do, I'll post it.

Ok - the only workaround is to change to style to dropdown combo and handle users typing in the textbox portion. It is a display problem only and doesn't affect the underlying data in any way.

Fixed in VFP8SP1. -- Sergey Berezniker.
Error #2072 -Cursor cannot be modified because it contains an unsaved record.

I am seeing this error in my clients' errorlog since we upgraded the app to VFP8. What does it mean? Is it a bug? It is not documented in VFP8 help. -- Randy Jean

You can repoduce this error with a simple form using buffering, a textbox, and a grid. Type into the textbox, then hit the button, which adds a record to the parent and child tables. Go into the grid and add child records, using a valid in the grid textbox to append blank records. You should get the error fairly quickly.

Well, here is the callstack from the errorlog. I can't see where a grid comes into play at all. It appears the user simply clicked the "New" toolbar button like they do hundreds of times a day...


We have found that this bug occurs with unbuffered cursors as well. We have a grid with a checkbox control linked to a logical field. If the user changes the value, any subsequent attempt to change the field value programmatically fails with error 2072. Blanking the recordsource property of the grid first makes no difference. The only workaround we have come up with is to copy the cursor to an array, ZAP the cursor and then APPEND FROM ARRAY prior to processing the records programmatically.
-- Jim Vahl

I have a grid with one column holding a container, that in turn has a r/o textbox, to show some of the memo text, and a button, to edit that text. If the does REPLACE... on the memo field, I get error 2072. So I added another control to my container - a hidden textbox - with the memo field as its controlsource; then I changed to assign a value to that control instead of the REPLACE (i.e. "this.parent.hiddenctl.value = ...") -- it works a treat. Gives you some clues as to how VFP is screwing up, too. - MP

I am getting an error with the help file in VFP 8
I have attempted to completely uninstall VFP8 and reinstall it both from the CD, and by copying the CD to the hard drive and installing it from there. None of this has worked so far. I have even changed my local intranet settings and advanced settings in IE to try and clear up the problem but that has not worked either.

Here is the error I get when I click on a page in the help file. This is just one example. I get a script error no matter what page I go to in the help file.

"A script error has occured on this page.
Line: 97
Char: 2
Error: Object required.
Code: 0
URL: "The URL Changes from page to page."

Do you want to continue?"

I can click yes and the new page does load and works correctly from what I can tell. I just want the error to go away, its annoying.

Any help would be greatly appreciated.


Keith Bonin
You're not alone. Same for me. José Constant

Uninstall VFP 8 and reinstall, but this time, go ahead and do the Windows Component Update, even if it doesn't seem to be required. That solved this one for me -- Tamar Granor

I did that and still have the problem. It's there in MDSN too, must be related to an IE something -- José Constant
Bug in VFP6SP5, fixed in VFP7 & VFP8 beta:
Basically, when an object's property that is an array has an _ACCESS method, you can pass a string literal as the subscript parameter, but when you pass a varaible (that contains a string) as the subscript, VFP6SP5 chokes with "Invalid Parameter"

See here _ Array Property Access Bug for code to reproduce it. (I submitted this to MS) - wgcs
If an Edit Box is bound to a memo field in an updateable local view, both GetFldState() and GETNEXTMODIFIED() return that the memo field/record has been modified if the user presses the Escape key while the Edit Box has the focus and there is a command button on the form with its' "Cancel" property set to .T.

The functions work as expected if the Edit Box is bound to a memo field in a table rather than a view.

This is reproducible under VFP 6 (SP5?) and 7 SP1 - I've opened a support incident with MS to hopefully get a confirmation.

- William Fields
Reported to MS File(cFile) Returns .T. when cFile doesn't exist even though cFile includes the full path to the file, if that path is on a drive different from SET('DEFAULT'). See VFP Function File - wgcs

UPDATE using SET RELATION and EOF() fails if EOF() is false on current record.
- Andrus Moor

CREATE CURSOR Cursor1 ( Field1 c(10) )
CREATE CURSOR RCursor ( Field1 c(10) )

SELECT Cursor1

UPDATE Cursor1 ;
    SET Field1='' ;
    WHERE !EOF('RCursor') AND ;
       Field1 IN (SELECT Field1 FROM RCursor )
* Result: 0
* Expected result: 1
messagebox( STR(_TALLY) )

VFP6 with latest service pack as of [2001.08.17 08:42:03 PM EST]:
The _shortcutmenu class of class library _menu in the FFC does not properly garbage-collect the popups it defines. The class defines any number of randomly named popups, and later, deactivates them -- but never releases them. The net effect is that the memory pool gradually fills with randomly named popups. To demonstrate, run the sample code several times over, then do a DISPLAY or LIST MEMORY. -- Willson De Veas

Sample code derived from

*? Create the shortcut menu object
loMenu = NEWOBJECT("_shortcutmenu",HOME(1)+"FFC\_menu")
WITH loMenu
   .AddMenuBar("Fox"   , [MESSAGEBOX("Fox")]   )
   .AddMenuBar("Wikis" , [MESSAGEBOX("Wikis")] )
   .AddMenuBar("Com"   , [MESSAGEBOX("Com")]   )
   .ShowMenu() && Show the menu

ALTER TABLE causes a "File does not exist" error [if the temporary files folder happens to have the System attribute set].


* replace c:\windows\temp with your temporary files directory
RUN attrib c:\windows\temp +S
CREATE CURSOR Test ( Field1 L )

Andrus Moor

I'm not sure if this is a bug or the help file is incorrect. The Help item for ALINES() (VFP6, SP3) states:

"A line feed (CHR(10)) or carriage return (CHR(13)) character denotes the end of a line. The end of the line can also be denoted with either combination of these two characters (CHR(10) + CHR(13) or CHR(13) + CHR(10))."

However, ALINES() with the following string produces:
cStr = 'BPR*I*4326.93*C*CHK************20010202~'
? ALINES(laryTest, STRTRAN(cStr, '*', CHR(10))) array with 11 elements. Not what I expected.

? ALINES(laryTest, STRTRAN(cStr, '*', CHR(13))) an array with 11 elements. Also not what I expected.
? ALINES(laryTest, STRTRAN(cStr, '*', CHR(13)+ CHR(10))) an array with 17 elements, the result I expected.

This bug is fixed in VFP7. -- Sergey Berezniker.

VFP leaves an unknown data session when passing SCATTER NAME objects between data sessions. This bug still exists in VFP 7. Supposedly it's harmless.

I encountered the following bugs using REPORT FOR ... NOWAIT command.
Those bugs are present in all Visual FoxPro versions.
1. Clicking Print button in Preview windows causes GPF (VFP 5) or
exception error (VFP 7)

2. In test program, if I comment out the line

create report TEST from TEST

clicking print button prints TWO lines!

Test program:

create cursor test ( test c(20) )
insert into test values ( 'line 1' )
insert into test values ( 'line 2' )
create report TEST from TEST
report form test preview for recno()=1 nowait

Andrus Moor
VFP6SP4: Calling a function passing an outline's SelectedItem.Text as the second parameter sometimes causes the first parameter to be "lost". ie:
 * In
if erase("ERASE_DIV", thisform.Outline.SelectedItem.text)
PARAMETERS cFunc, cFunc2
* What happens is PP=1 here
*  and cFunc=thisform.Outline.SelectedItem.text

This may not happen in every situation, but Once is too often for me!

Hmm, the fact that the program that exhibits this problem is named "ERASE", the same as an existing FoxPro command, is immediately suspect to me. I'd be curious to know whether the problem doesn't happen when passing SelectedItem.Text to a differently named program. -- Willson De Veas
VFP6SP4: OBJNUM() cannot find the @..GET number if the variable in the @..GET is an object property... See VFP Function Obj Num for more details. - wgcs
SET KEY very slow with integer indexes (tested with VFP 6)
Try this:
CREATE CURSOR test (id i)
FOR i = 1 TO 100000

    INSERT INTO test VALUE (i)
? SECONDS() - a

- If you replace the line "SET KEY TO 2000" with "SET FILTER TO ID=2000" and it's fast again.
- If you replace the type of ID by N(8), "SET KEY" is fast again.

The problem only shows when SET KEY is used in combination with an integer indexes. If I try this workaround: indexing on BINTOC(id), it doesn't work either!
Strange isn't it ?

Indexing on str(id) works ok. Even more strange, but at least you have now workaround. -- Vlad Grynchyshyn

This problem also exist in VFP7. -- Manu
Corrected in VFP8 Beta !! -- Manu

Scan End Scan -- ENDSCAN selects the Select() area that was selected when the SCAN was entered... Even if you leave the SCAN..ENDSCAN by means of a RETURN in the middle! This makes it difficult to have error catching code inside a SCAN that would RETURN out of the function. (click Scan End Scan for sample code)

While this is probably designed-in behavior, it certaintly seems like undesirable behavior to me!
-- wgcs
There is a performance bug in SUBSTR(), or in the documentation by failing to disclose SUBSTR() performance degradation with long strings, beginning at 64k.

I ran across it by attempting to reverse "War and Peace" as an excercise.
After some discussion and testing by Foxfolk on Compuserve others confirmed the problem.

Further testing shows this performance problem extends to every string function I tried.
LOCAL nStart, cDummy, N , i

FOR i = 2 TO 32
cDummy = REPLICATE ("a", 2^i)
nStart = SECONDS()
  FOR N = 1 TO 1000
  SUBSTR(cDummy, 1, 1)
? i, SECONDS() - nStart

Work arounds for long strings
Do your work on strings less than 64k long.
OCCURS( CHR(10) )  && check CHR(13) also, to determine how many arrays of 65000 elements you need.
SUBSTR(), LEFT(), RIGHT() to break up the long string into ARRAY sized pieces.
ALINES() will quickly populate the ARRAY elements.
SUBSTR() will handle the 64k max strigs in the  ARRAYs elements.

The above took 3-4 minutes to reverse War and Peace. FREAD(somefile,1) and FWRITE(Anotherfile,1) will copy a 3.2MB file one byte at a time (normal order) in 157 seconds on a P100 machine.

The Debug Event Tracker shows the Grid.MouseDown, Grid.MouseUp, Grid.Click events each fire just before the corresponding Grid.ColumnX.Header1... events; however, code placed in the grid events is never executed. - ?wgcs
- Category VFP Events
public goForm
goForm.visible = .t.
goForm.txtTest1.Visible = .T.
define class TxtBug as textbox
  procedure interactiveChange
  This.left = thisform.textwidth( trim( this.value ) )

Any chance this article covers what you describe?
Q207797 Offsite link to;EN-US;Q207797 - BUG: Cursor Jumps Around when Typing in Edit Box

Not only does it move the box around as you type (that is expected), but it flips the text around backwards (that doesn't seem right). -- ?CFK
I don't disagree that it doesn't seem right, but VFP seems consistent that anytime the moved event gets fired of the textbox that the cursor position gets reset to the beginning (hence every character is added at the beginning). If you save Sel Start before changing Top or left and restore it afterwards then it works better. - ?wgcs
Add this code to the above class definition, and it seems to fix the problem nicely:
PROCEDURE left_assign

  lnSelStart = This.SelStart
  This.Left = tnLeft
  This.SelStart = lnSelStart

Though the MSDN article Q191222 Offsite link to;EN-US;Q191222 states that VFP6 supports the MonthView control in the MsComCt2.ocx
MonthView control, there is no way to programatically determine how wide the calendar actually is:
the one method provided to do this (ComputeControlSize) chokes in VFP with an "OLE error code 0x80020005: Type mismatch"
Code to Reproduce:

x.AddObject( "y", "OleControl", "msComCtl2.MonthView" )
x.y.visible = .t.
wid = 10
hig = 10
x.y.ComputeControlSize( 1,1, wid,hig) && This blows with a 0x80020005 error

- ?wgcs

As a workaround for the problem outlined here by wgcs I created a VC++ DLL that can be called from VFP... Here is the VFP CODE and the VC++ code:

VFP - Call and use of DLL
LOCAL lnWidth, lnHeight
STORE 0 TO lnWidth, lnHeight
WITH thisform.olecontrol1
    .object.font.size = 9 && Sometimes necessary to make control sized right
    DECLARE GetMonthviewControlSize IN MyDLL.dll OBJECT, SHORT @, SHORT @
    =GetMonthviewControlSize(.object, @lnHeight, @lnWidth)
    CLEAR DLLs GetMonthviewControlSize
    Messagebox(allt(str(lnHeight)) + " : " + allt(str(lnWidth)))

VC++ Function code for MyDLL.dll
//Don't forget to add "GetMonthviewControlSize" to the .def file.
     // Otherwise it won't know that this is an exported function

      // The exported function, called from Microsoft Visual FoxPro
      void _stdcall GetMonthviewControlSize(IUnknown *pUnk, short &pHei, short &pWid) {
            // QueryInterface for a IDispatch pointer...
            IDispatch *pDisp;
            float pHeight;
            float pWidth;

            HRESULT hr = pUnk->QueryInterface(IID_IDispatch,
                                             (void **)&pDisp);
            if(FAILED(hr)) {
               //QueryInterface() failed
            else {
               //We got the dispatch pointer!

               // Attach dispatch to a COleDispatchDriver class.
               COleDispatchDriver disp(pDisp); // Uses constructor

               static BYTE parms[] = VTS_I2 VTS_I2 VTS_PR4 VTS_PR4;
               // DispID 0x0000001c of ComputeControlSize found using VC++ OLE/COM Object Viewer
               disp.InvokeHelper(0x0000001c, DISPATCH_METHOD, VT_EMPTY,
                                 NULL, parms, 1, 1, &pWidth, &pHeight); //Call to ComputeControlSize
               //Cast float as short and put it in our out parameters
               pWid = (short)pWidth;
               pHei = (short)pHeight;

dbGetProp(..., "default") doesn't return the expression in the "normalized" form. The workaround is to wrap it with NORMALIZE(), but thats a hack. -- ?CFK

create database test
create table foo ( lFid1 l default MyFunc1() and !MyFunc2() )
index on MyFunc1() and !MyFunc2() tag test

* these 3 function should return the same thing, but they don't
* One of these things is not like the other, one of these things is not the same...

? "#1", dbGetProp( "foo.lFid1", "field", "default" )
* #1 myfunc1().AND..NOT.myfunc2()
? "#2", key()
? "#3", normalize( "MyFunc1() and !MyFunc2()" )

function MyFunc1
return .t.
function MyFunc2
return .t.

If you produce a file by using SET PRINTER TO and then use "@ Say" commands to create the file, and the last command you issue is "EJECT" before setting the device back to the screen and issuing SET PRINTER TO, then the last "@ Say" command issued BEFORE the EJECT, is Output AFTER the Form Feed the Eject caused.
Here's some code to reproduce the problem:
SET PRINTER TO report.txt
@ 0,0 say "Line zero Page One"
@ 1,0 say "Line One Page One"
@ 2,0 say "Line Two Page One"
MODI COMM report.txt

That is, this demonstration code below causes output that looks like this:
Line zero Page One
Line One Page One

Line Two Page One

(where the box character is a FF CHR(12); the output SHOULD look like this:
Line zero Page One
Line One Page One
Line Two Page One

- ?wgcs

The above is a common problem, but is not really a bug. @says are a different beast. You can get these funny results by mixing them with the commands used with the ?, ??, and ? commands. Only use set printer on, set printer off and eject together. For the others, use set device to print, @ say 0,0 "" {for the equivalent to a page eject) and set device to screen. "Set printer to" is common to both sets of commands.
These kinds of problems can drive you crazy!!!!

- mws

There is no way to add a "PM Item" that has command line parameters to a VFP Setup Wizard build.

For example: If I install an executable (not a VFP executable, just a viewer utility) called VIEW.EXE and want to use it to view my specially formatted file READ.ME both with my project, and want to add an icon to the start menu called "View Special Readme file", then, in the Setup wizard, I click the "PM Item" check box next to READ.ME, and in the dialog that appears, type (no quotes): "%s\view.exe %s\"

What results when the user actually installs is the icon gets quotes around the entire thing and from then on windows thinks it's a long file name with spaces in the middle.

So, I tried adding quotes in the middle like this:

%s\view.exe" "%s\

Upon installing, I get a Setup error (vfp5 gave an error number I don't remember, vfp6 now doesn't give an error number), basically because it found a quote in the SETUP.STF file that didn't belong. (almost in accordance with the MSDN Library article ID Q153874 Offsite link to;EN-US;Q153874, though this article is referring to the Icon Name in the "PM Item" ). That line in the SETUP.STF is fully surrounded by double quotes and the quotes in the middle confused it.

From examining the SETUP.STF file, I learned that embedded quotes should be doubled (ie: "" produces a single quote). So I tried again, using doubled double quotes, ie:
%s\view.exe"" ""%s\

This, suprisingly, yields the correct results in the final Icon shortcut file after the user installs. However, the shortcut doesn't work: if you then go to the properties on the shortcut, the command line looks like this:
"%s\view.exe" "%s\"
Which appears correct, except that when you click it, windows reports the file "READ.ME" is missing... if you click OK after going to the properties for that shortcut, the shortcut NOW works correctly (ie: loading and saving the shortcut's properties fixes it) This is, of course, still unacceptable.
I Submitted this to Microsoft.
-- wgcs
Using a dummy day and month along with a 2-digit year to get a 4-digit year year() will return 2000 if the 2-digit year is empty.

lcYear = '99'
year(ctod('01/01/' + lcYear) returns 1999

lcYear = ''
year(ctod('01/01/' + lcYear) returns 2000

-- ?ERGilmore

Microsoft is simply defaulting lcYear to '00' for you [g] Art Bergquist

Tooltips do not remap in scrollable forms.
If one creates a scrollable form and adds controls in the main view port with tooltips. Those same tooltips appear at the corresponding X,Y coordinate after scrolling to a different view port. Any controls added to another region (view port) of the form, which have tooltips, will not display these tooltips. -- Jeremy Lanctot

This is fixed in VFP7.
-- Jim Saunders
"select ... where m.var" works for numeric vars, but not arrays.
Code shows it working for lnX, but not for laX[1].
local lnX, laX[1]
m.lnX = 1
m.laX[1] = 1
create table foo ( iFid1 i )
select * from foo into cursor tmp where iFid1 = m.lnX
select * from foo into cursor tmp where iFid1 = m.laX[1]
&& error #67 "Expression evaluator failed."
&&  Line #6 "select * from foo into cursor tmp where iFid1 = m.laX[1]"

This works fine in VFP7 and 8. I think there may still be a place where m.laX[n] will hose you.
Build an exe file with debug info checked in Project Manager.
Run it in stand-alone mode and look for message(1) value set by error.

It seems that message(1) returns almost a random line from the program.
Also, a chr(13) is added to the end of message(1).

-- Andrus Moor
  • If the vcx doesn't exist, build it.
  • you can then quit VFP and run the following program
  • and be sure that the 3 modi classes are the only things being run.
  • Close the class designer however you like.
  • I click on it and hit escape
  • not fixed in SP4
if !file( "cLib.vcx" )

wait window nowait "select class and hit escape to close it"
modify class cContainer2 of cLib
wait window nowait "do it again..."
modify class cCustom3 of cLib
modify class cCustom1 of cLib && error #1948 "Cannot modify a class that is in use."

function lBuildVCX()

local lax(1)

create classlib cLib
create class cCustom1 of cLib as custom nowait
create class cCustom2a of cLib as cCustom1 from cLib nowait
create class cCustom2b of cLib as cCustom1 from cLib nowait
create class cCustom3 of cLib as cCustom2a from cLib nowait
create class cContainer1 of cLib as container nowait
create class cContainer2 of cLib as cContainer1 from cLib nowait
aSelObj( lax, 1 )
lax[1].NewObject( "oCustom2b", "cCustom2b", "cLib" )


function lSac()
* Save and Close
activate window class
SYS(1500, '_MFI_SAVE', '_MSM_FILE')
SYS(1500, '_MFI_CLOSE', '_MSM_FILE')

Can't embed && in a string. I guess it turns the rest of the line into a comment, even though the program editor colorizer is smart enough to know that it is not a comment.

? "&&"
error#36 Command contains unrecognized phrase/keyword.

Workaround: ? "&" + "&" && so you don't have to lookup the number to send to chr()

The question, of course, is if it's a bug in the syntax parser, or in the syntax highlighter. I would rather that my line errored on compile than not, if I mistakenly coded:
lcVar = 'This is the text that I expect to go into the variable that I referanced earlier in the line... "&& This line doesn't work right
So I say that the syntax highlighter is wrong, in this case. -- Peter Crabtree

Also, just to note a similar poor parsing by the syntax highlighter; if a line is a comment and ends with a semicolor (';') the comment continues onto the next line, though the syntax highlighter doesn't make that fact clear -- ?wgcs
Fixed in VFP 8 SP1. :) -- Peter Crabtree

The RemoveClass( ) method takes a parameter tlConfirm. If you pass .T., it will prompt for confirmation before deleting the class or classlib. If you pass .F. and are removing a classlib, not only does it not prompt, but it skips the deleting also.

The method is mentioned in the docs, but it doesn't even mention the parameter.

Docs: "Class Browser Methods -- RemoveClass( ) Removes the selected class in the class list from its associated class library (.vcx) file."
? chr(123)
generates always a Syntax Error

? "{123}"
-- Ibrahim Oezyurt
This is by design. See Vfp Command Question Mark Question Mark Question Mark
Recently I made some tests for speed. I tried to display following expression:
? transform((seconds()-m.StartSeconds)/m.NumberOfTries,'999 999.99999')
It always shows '0.00000'.
? str((seconds()-m.StartSeconds)/m.NumberOfTries,12,5)
displays correct result: '0.00240'.

-- Vlad Grynchyshyn

This is a SET DECIMALS issue. If you SET DECIMALS TO 12 before this, it works as you think it should. The reason the str() function works is because the decimals parameter overrides the current SET DECIMALS setting. If you are going to do any fractional math, make sure to check your SET DECIMALS setting -- BradKarsjens
PemStatus cannot check if a property, event or method is Hidden.
This ommission was mentioned in the Hacker's Guide to Visual FoxPro 6.0 :
"Although you can find out whether a property is protected, there's no way to check whether it's hidden. We suspect that Microsoft simply hasn't noticed yet that that's a useful piece of information."
Annoyingly PemStatus([object],[hidden method],5 - "Defined Property, Event, Method or Object") returns True even though the error message when you call the hidden method is [Property "[hidden method]" is not found (Error 1734)] In VFP7 you can use AMEMBERS to return an array of hidden properties, events and methods : AMEMBERS([array],[object],1,'H')
-- Rhodri C Evans
C0000005 Error Using Intellisence to Pick Up a Custom Method Name in Form Editor:

I finally installed VFP7 on my Win 2 K machine thinking I'll play with it for a while and if everything is OK I'll swith from VFP6 to it completely. After a few days the following started:

I can create a new method in a form and when I call the method from within another method using This Form.MyMethod (picking it up from Intellisence List) and try to place a "( " at the end of MyMethod, leather Foxpro crashes with the C0000005 error.

The problem occurs only with custom methods.

The problem cannot be reproduced consistently. However, once it occurs, it will occur EVERY subsequent time I attempt to add a left parentesis to a custom method name after picking it from the Intellisence list...

Anyone had the same experience?


Rosty Vygovsky

I have this all the time with VFP 7. not sure why but, like you say, only with custom methods

I gave up used 6 until vfp8 came out Tim Hustler

Same here in VFP 7 SP 1--but only if I first type "THIS." or "THISFORM." before typing the method name. You can turn off Intellisense (Tools>Intellisense Manager, uncheck Enable Intellisense) to stop it for the duration of your session, but the off setting doesn't persist between sessions.

Microsoft never officially acknowledged this bug but it doesn't occur in VFP 8, VFP 8 SP 1, or VFP 9 Public Beta. There remains some question as to whether the fact that the later versions require Win 2000 and above "fixed" this problem, or if it was intentionally fixed by Microsoft. As I recall, people running VFP 7 on NT-based OSes never had this problem. My strategy has been to type out the method name and leash parentheses first, then go back and prepend "THIS." or "THISFORM." That prevents the crash. But sometimes I forget to do that, and I still send in the Dr. Watson reports whenever it happens to me in VFP 7 on Win 98 SE, just for grins. -- Ken Dibble

PemStatus is badly broken in VFP8 and VFP8 SP1. __ PEMSTATUSBug Probe
Fixed in VFP9. -- Peter Crabtree
(Discovered by Chris Mattson)
In VFP9 Only (not fixed as of SP2RC1) CALCULATE SUM( fieldlist ) will give a buffer overrun error if fieldlist larger than around 115 bytes. -- Eric Selje

Contributors: Carl Karsten wgcs Jeremy Lanctot Andrus Moor Ibrahim Oezyurt Vlad Grynchyshyn Rhodri C Evans Eric Selje
Category VFP Troubleshooting Category VFP Bugs
( Topic last updated: 2011.11.13 06:44:47 AM )