A: Well, probably that someone already had time to close it, if it in general opened. The work with fields given from cursors "binding" to form objects, requires to hold open all cursors, used in a form. It does not cause difficulties with one active form (using Form.DataEnvironment.AutoOpenTables = .T. (Default), and on the contrary Form.DataEnvironment.AutoCloseTables = .F.), but can result in problems at simultaneous work with several forms, if in them are available, for example inconsistent installations Set Relation to Е In such cases are best for using property Form.DataSession established to state 2-Private Data Session (in this case is possible to to allow and Form.DataEnvironment.AutoCloseTables = .T.). Here it is necessary to warn, that in each of sessions of the data, you should see to it about a set of settings Set Е, at once after opening session (in Form.DataEnvironment.BeforOpenTable()).

A: The analysis of not working variant has shown, that the problem was in "careless" use of function TABLEUPDATE() at the buffered source of the data. It is necessary always to analyze returned value of this function, and if it will matter .F. It is necessary in addition to use function AERROR() for specification of the reasons of failure of system in saving of the data. (Visual FoxPro 5.0 has an example of a class DataChecker in Vfp\Samples\Classes\Samples.vcx demonstrating correct ways of saving of the data. A more simple way of saving of the data you can see in Tasmanian Traders Sample: a method tsBaseForm.Save () in library of classes Vfp\Samples\Tastrade\Libs\Tsbase.vcx). In the given concrete case rejected saving by the trigger of addition of the data of the appropriate table.

A: For a choice any of the element contained in a class-container enough on it click right mouse key and in the revealed menu to choose item Edit, then to you there are accessible to editing objects of the top level of this class, etc.

A: Ideal, but, unfortunately, not always possible is triggers of the appropriate sources of the data, so in the trigger update for some table attempt to make changes to the same table is finished by a mistake. The mistake here too is caused by attempt of moving pointer of active record, that excludes an opportunity of scanning of the table with the purpose of performance of some calculations. Thus, if the results of calculations are required be to be made and to be kept in fields by this, i.e. the changeable record, or for calculations to you needs scanning the changeable table, most likely it will be necessary to you to change a method Save of the form, i.e. at once before TABLEUPDATE() to make a call of an additional method, for example PrepSave, which will execute necessary calculations and changes before saving record. It is necessary to tell, that the procedure carrying out calculations and making these changes in the table should be issued as the stored procedure called from the form.
It is necessary also to note, that the additional difficulties at you will arise at use of edited object Grid, as it independently makes saving of changes from buffers of the source at moving from record on record. In the latter case you will need to redefine Valid-function of object displaying the data in the column, from which and to carry out a call of a method Save of the form. And still best variant consists in such designing of structure of the tables, that all necessary changes could be executed in the appropriate triggers, for example, by allocating calculated fields in the separate table and by connecting it in appropriate way with initial.

A: For this purpose you should 1) save your form as a class ('File\Save as class...') in your vsx-library; 2) to open this library using Class Browser (Tools\Class Browser); 3) by choosing thus created class in Class Browser to execute item 'View Class Code' (button on the panel of tools).
(Class Browser in version 6.0 supports viewing many types of files [see. Files of type at opening], including scx, therefore is not necessary to do it through library)
In general means of debugging in VFP 6.0 are very variously, personally I frequently simply insert a command SET STEP ON into a method, the work code of which is necessary for observing under debugger. Can be here pertinently remind, that the search (CTRL+F) has an option Scope: All objects allowing to search a fragment in all methods of a class, and not just in current.

A: Try in all events MyForm.PageFrame1.Page[i].Activate() to add a lines

DODEFAULT()
This.Refresh()
*
* ... or ...
*
DODEFAULT()
IF !ThisForm.App_picbtns1.EditMode
	 This.Refresh()
ENDIF

... or something similar it, but is necessary with This.Refresh(). Better for this purpose to create a base class MyPageFrame, and to use derivative from it in the forms.

A: Most likely, at your form have property MyForm.DataSession = 2-Private Data Session... In this case, for each such form, is created a session of datas but SET's with which, have not any relation to SET's in Default Data Session (1)... Therefore in each such form they are necessary to setting it's each time at once after creation of new Data Session for the form...
There are two places where it better to make:
- If use Local View (SELECT's), most likely it is necessary also SET DELETED ON before opening, and then it is better to locate a code similar following:

IF ThisForm.DataSession # 1
   SET DATASESSION TO ThisForm.DataSessionID
   SET TALK OFF
   SET DELETED ON
   SET MULTILOCKS ON
   SET EXCLUSIVE OFF
ENDIF

in an event MyForm.DataEnvironment.BeforOpenTables()
- If told above is not critical, a the above same code may be locate in an event MyForm.Load(), i.e. before creation yours window Control's, probably it is necessary still add

IF !EMPTY(ALIAS()) 
     LOCATE && or GO TOP
ENDIF

A: It's enough in main menu to keep appropriate menu items... see menu items after generation of the menu through Menu\Quick menu

A: If in brief, in your modal form call a method ThisForm.Hide () in MyModalForm.cmdSaveValue.Click() [carefully read article in MSDN on Hide() method :-)], in this case, the next after loMyModalForm.Show (1) command will be executed, and reference loMyModalForm still valid (in any opposite case is already desroyed :-)... also this reference can be used for returns value from MyModalForm for example, through special public property oMyModalForm.uRetValue :-)... And to transmit parameters value to your MyModalForm by use parameters in MyModalForm.Init(tuP1[,tuP2...]), probably by additional private-properties for these parameters, "to inform" them values up to an event MyModalForm.cmdSaveValue.Click() :-)
The interesting candidate solution was has shown by Mike Korneev on fido7 news RU.VISUAL.FOXPRO:

*********** any.prg
local lc_Tmp
lc_Tmp='1234'
createobj('ff',@lc_Tmp)
? lc_Tmp

define class ff as form
	autocenter=.t.
	width=200
	height=100
	add object txt as textbox with top=20, left=50, width=100
	add object cmd as commandbutton with top=60, left=50, height=25, width=100
	
	func cmd.click
		thisform.hide
	endfunc
	
	func init(rc_Val)
		this.txt.value=rc_Val
		this.show(1)
		rc_Val=this.txt.Value
		return .f.
	endfunc
enddef
********** end of any.prg

A:
- the most simple method: to insert into menu item of open the form as expression in Skip for: !WEXIST('MyForm'), but it if exist menu item for call of the form...< br >- other variant to store into array of the all references somewhere in a class MyApplication, and open/realize of the forms by a method of this class, which purely and will be correct ruling start/erasure... In other words exactly how Application Wizard VFP 6.0 makes in:< br>Class Library: HOME()+'wizards/_framewk.vcx'
Method: DoForm (..., tlNoMultipleInstances, ...)
While the mode is installed through Application Builder on a tab Form - one instance form...
- At last, there are no problems to write in a base class for all your forms in an event MyBaseForm.Load() look all of the references in _SCREEN.Forms(), and return .F. if the form with such name already exists.