Microsoft KB Archive/310179

= How to file a bug report for Visual FoxPro =

Article ID: 310179

Article Last Modified on 9/3/2004

-

APPLIES TO


 * Microsoft Visual FoxPro 7.0 Professional Edition
 * Microsoft Visual FoxPro 8.0 Professional Edition

-



This article was previously published under Q310179



SUMMARY
There are various that help the Visual FoxPro development team reproduce and fix the issues that are described in your Visual FoxPro bug reports. This article contains an overview of some of these techniques. You may also find these techniques useful in other situations.



MORE INFORMATION
After you have read the guidelines in this article, see the following article in the Microsoft Knowledge Base for more information about how to submit a bug report:

867477 Microsoft Visual FoxPro bug report and feedback

When you report a suspected bug in Visual FoxPro, make the report as automatic as possible. If you can copy your code out of the report and paste it in Visual FoxPro or an automated test tool, it is much likelier that the error will be reproduced and fixed. For example, the following is not an optimal way to report a bug:   Create a program, and then insert the following code: DEFINE CLASS fred98 AS session OLEPUBLIC PROCEDURE mike4 RETURN &quot;One ring to rule them all&quot; ENDPROC PROCEDURE mike5 RETURN &quot;One ring to bind them&quot; ENDPROC PROCEDURE jenni3 RETURN &quot;One ring to bring them all and in the darkness bind them&quot; ENDPROC ENDDEFINE  Put the program into a project, and then build a multithreaded DLL. Use a CreateObject function on the DLL that you just created, and then call Mike4.

Although, those are perfectly valid steps, they require excessive modification before they can be added to a test suite. Additionally, the report includes methods that do not have anything to do with the problem at hand.

A concise description of what you expect is particularly important, and indicating why -- for example, if the Help file states that something should work, the bug may be located in the Help file, and also in the code.

Notice how the following steps are very clear, include only relevant code, describe exactly the behavior that you expect to occur, and then describe the behavior that actually occurs:   Run the following code: TEXT TO lcRepro NOSHOW DEFINE CLASS reproClass AS session OLEPUBLIC PROCEDURE reproMethod RETURN &quot;This should return correctly.&quot; ENDPROC ENDDEFINE ENDTEXT

STRTOFILE(lcRepro, &quot;classPrg.prg&quot;) BUILD PROJECT reproProj FROM classPrg.prg BUILD MTDLL reproDLL FROM reproProj

loReproObj = CREATEOBJECT(&quot;reproDLL.reproClass&quot;) lcRetVal = loReproObj.reproMethod Expected behavior:

lcRetVal equal to &quot;This should return correctly.&quot;

Actual behavior:

Visual FoxPro starts humming a marching tune. 

In the &quot;More Information&quot; section of the bug report, you can include your operating system version (including service packs), computer information (video card and driver are relevant for problems involving screen display, and occasionally other issues), and the results of any other testing that you have completed. If you have a workaround, provide that also. Documentation of a workaround can be better than fixing the bug, because bug fixes can introduce bugs elsewhere in the code.

As another possibility, you may have to demonstrate what occurs when you click a particular button. However, you cannot add code to a button at runtime. Therefore, you must create a button class first, as in the following example: loForm = CREATEOBJECT(&quot;Form&quot;) loForm.AddObject(&quot;cmdTest&quot;, &quot;cmdRepro&quot;) loForm.cmdTest.Click

DEFINE CLASS cmdRepro AS CommandButton PROCEDURE Click MESSAGEBOX(&quot;This is the custom click button we defined.&quot;) ENDPROC ENDdefine However, notice that this sample code is not as good an example as the previous one. Because it forces the tester to view output onscreen instead of comparing a string value, it cannot be automated in the same way.

If you want to show an error that occurred while you were designing the form instead of running it, you can use the ASELOBJ function, as follows: MODIFY FORM myTestForm NOWAIT ASELOBJ(laForm, 1) && The 1 gives the container of the selected object. && While there is not a selected object in this case, && you still get the form designer reference. loForm = laForm(1)

loForm.AddObject(&quot;cmdProblem&quot;, &quot;commandButton&quot;)

loForm.AddObject(&quot;txtDisplay&quot;, &quot;textbox&quot;) loForm.txtDisplay.Top = 100 loForm.txtDisplay.Width = 200 Finally, if all else fails, you can use the KEYBOARD command to stuff keystrokes into the IDE, as follows:   Run the following code: CREATE FORM form1 NOWAIT ASELOBJ(laObj, 1) laObj(1).AddObject(&quot;cmdTest&quot;, &quot;CommandButton&quot;) laObj(1).cmdTest.SaveAsClass(&quot;corrupt2&quot;, &quot;myButton&quot;)

CREATE FORM form2 NOWAIT ASELOBJ(laObj, 1) laObj(1).NewObject(&quot;cmdTest&quot;, &quot;myButton&quot;, &quot;corrupt2&quot;) laObj(1).cmdTest.SetFocus RELEASE laObj KEYBOARD &quot;{ALT+F}L{PAUSE 1}myButton{TAB}corrupt2{ENTER}{PAUSE 1}Y{PAUSE 1}&quot; KEYBOARD &quot;{CTRL+W}&quot; KEYBOARD &quot;{CTRL+W}&quot; </li> Quit Visual FoxPro.</li> Start Visual FoxPro, and then try to MODIFY FORM form2.</li></ol>
 * !* This is where it gets interesting: You cannot SaveAsClass with a live
 * !* reference. Therefore you have to stuff keystrokes into the menus and
 * !* dialogs.
 * !* ALT-F + L = Save As Class...
 * !* myButton = name of class
 * !* corrupt2 = class library
 * !* y = Yes, overwrite previous definition
 * !* Close the form designer windows.

Keywords: kbhowto kbinfo KB310179

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.