On Mon, 23 Mar 2015 03:35:29 +0200, Wayne Graham <equiline2@gmail.com>  
wrote:

> OK I have no idea what is causing this.  Hopefully I am just ignorant  
> and someone can point me in the right direction.
>
> I have a "Main" form containing a Grid & a Seeker. It works perfectly  
> and calls other Forms and Menus etc  I can add any form I wish and pass  
> parameters do Adds & Edits and it all works fine. BUT..............
>
> Every time I add a second Seeker/Grid combo to the design it falls over  
> AFTER I close Dbase and re-open it.  If I dont close Dbase the second  
> Seeker continues to work perfectly and I can leave both forms open and  
> swap from one seeker to the other.
>
> If I close it the second Seeker almost always fails.  My testing this  
> morning indicates it always fails but I am not 100% sure on that.
>
> I am using the following code for the second Seeker form.  I have tried  
> umpteen times with variations in naming conventions etc with the same  
> result.
>
> I Know the use of a PUBLIC variable in the OnClick event will not be  
> approved by some but it works for me in this situation as this piece of  
> code is the only user of the variable across several sub prgs and it  
> should have no bearing on the problem.  Am planning to tidy it up later  
> and left it to show exactly what I am doing


I can't see anything in your form that would cause problems as long as you  
don't use the same classname for different forms.  Having a seekersql  
control named seekersql1 on many forms is no different to having a  
pushbutton control named pushbutton1 on the forms and that is something  
that is done every day without problems.  I don't normally use seekersql  
but a quick look through the seekersql.cc code also doesn't show anything  
that could cause the problem.  It seems that something in x_data.prg is  
upsetting things.

Your x_data.prg creates a dataset.  How is this done and how do other  
forms access it?

Generally the advice on public variables is "Don't use them".  Now that  
dBASE has gone OOP it is, in any event, better practice to use  
user-defined properties of the _app object instead if you want a value to  
be available to all forms, reports and programs. In this case you would  
use _app.hos_name instead of the public variable hos_name.  It is,  
however, more in keeping with OOP practice to keep all forms and programs  
self contained.  Instead of letting the program fetch a value from a  
public variable or the _app object rather pass the value to the target up  
front as a parameter.

Again, generally speaking, only use variables where that variable will  
only be used inside a function.  If you need the value to be available  
elsewhere after the functions has done its work rather use a used-defined  
property of the form (or one of the objects on it) instead.

If you installed the dUFLP according to the instructions on Ken Mayer's  
website dBASE will have created a source alias dUFLP and the attached  
examples should run without a problem.  If the source alias doesn't exist  
you will need to comment out the first line of the form class definition  
and uncomment the second.


class mb_x_dataForm of FORM
    set procedure to :duflp:seekersql.cc additive
//   set procedure to "D:\Other Documents\DBase8\Code  
Examples\seekersql.cc" additive
    with (this)

In the pushbutton's onClick event handler the variable hos_name is not  
declared before it is created and populated.  This creates the variable as  
PRIVATE.


Mervyn.