Subject Re: VARIABLE DECLARATION From Andy Taylor <andy.taylor@which.net> Date Fri, 13 Apr 2018 17:46:20 -0400 Newsgroups dbase.getting-started Mustansir, Thank you for your kind words. The reason that I took the time to explain form execution is that I remember clearly the time I spent being puzzled when first looking at OOP code in dBASE.  Also how excited I was when the concepts and ideas started dropping into place. So, to your question and my answer: Yes, the row pointer in form.mq1.rowset will remain at the same position until something happens which will move it; such as form.mq1.rowset.next(1) being executed somewhere else in the form. Forms can easily be built without using queries or interacting with data tables in any way. Those forms that do use data tables usually do so through adding one or more query components to the form. It is the query component that contain a rowset object which in turn manages access to the table fields. It is also possible to use workAreas to access data tables in dBASE 11.3 within forms, in fact the browse object is provided for this purpose. If you imagine a rowset as very similar in concept to a workArea you should get more comfortable.  The difference being largely a matter of language used to access the fields. In a workarea you use TableAlias->Fieldname to access the content In a rowset it's form.queryName.rowset.fields["Fieldname"].value   Thus queryName.rowset takes the place of TableAlias. In my own programs I tend to mix and match OODML and XML code depending on which is easier to code or gives better performance.  There are purists who say only use OODML but for example if you want a live record count on a dbf table it's much quicker to use XML Count rather than it is to use rowset.count(). I do try to use query.rowset in all my new stuff... because of the increase in functionality and ease of programming when using objects Andy   > Dear Andy > > This mail is so important and I have read it several times just to > understand form execution mechanism. Truly you are an expert on the > matter and many others. > > Here as I understand readmodel() is similar to READ in DOS, where > execution stops waiting for user response. But rest all commands are > executed and load in memory. Based on mouse and keyboard action they > respond. Component order are based on Z order (if Tab is followed) but > any component can be executed independently (if enabled). This can be > for all wfm, rep, mnu objects. > > Several times Ken Sir mentioned that data objects can be treated > differently as they can not be associated with form.  But we have > queries attached to a form. There are situations where form objects are > in the same commands with data objects. On otherhand we have SQL > statements can be executed independently within the form. > > One may ask What is the point. I am unable clearly understand how and > where data objects can be used correctly in a form. Just an example On > one event I have command form.mq1.rowset.findkey(form.cbitem.value). If > the record is found (event execution completed), and user clicks another > different event, will form.mq1.rowset record position remain to the same > record (assume it was not referred in the current event) as it stopped > at found position. > > Best Regards > Mustansir > > > On 3/8/2018 1:50 PM, Andy Taylor wrote: > > Therefore, once the form opens, f, which is local in scope, disappears. > > What about mipdname? Well, that was private in scope and as we have hit a return point on the processing of ghor22.wfm > > it too will disappear. > > > > The only thing left (hanging in memory) is the form. The form can, obviously, no longer see f, mipdname or bModal. > > The reason the form stays in memory is because windows has an open handle to it.  Once you close it the form will > > also disappear from memory.  This is handled automatically by dBase and works as expected UNLESS your programming > > has managed to insert another memory pointer to that form, in which case it will still exist in memory. That, however, is > > beyond the scope of this discussion. >