Call a button click event in a form from a PRG

[thegame8311]

I was wonder, if there is a way to call a button click event in a form, from a PRG. I Read somewhere about Read Events but I am not if that is the way to go about it, much less not really understanding what Read Event are

 

[Dan Freeman]

READ EVENTS has nothing to do with calling a form's method from a PRG.

You need a reference to the form object. The most generic, assuming the form is currently active, is:

_Screen.Activeform.Method()

Dan

 

[Mike Lewis]

The best way to do this is to move the code from the button's Click method to a separate function (in a PRG). Then call that function from the Click, and also call it from wherever else you want.

That way, you separate the functionality from the user interface (the button). It also means that functions outside the form are not dependent on the form itself (so you could delete the button without it affecting anything else, for example).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[TamarGranor]

Mike's answer points out that there's something not quite right in your design here. Why do you need to call a control's method from outside the form?

Tamar

 

[thegame8311]

the code in the button is this:

thisform.button1.click
thisform.button2.click

so in the prg do i need to use the form name instead of thisform. or something else?

I tired using the _Screen.ActiveFrom.Method like this:

_Screen.ActiveForm.Click

I clearly am missing something, but what?

 

[Dan Freeman]

As the others have mentioned, there's a really bad code organization problem here. But since you won't undo that, you need to reference the object on the form.

_Screen.Activeform.Button<n>.Click

 

[thegame8311]

I was taught better about code organization, which I will fix, but I have been brainstorming alot, so it is going to be a little disorganized.

Now I'm not really ignore you guys, I'm trying to understand more

So here is the exact code in my prg

DO FORM lp1
_Screen.ActiveForm.AutoPlay.Click
[code]

AutoPlay is the name of the button.

 

[AlastairP]

Why don't you just have a form method, put your code that's in the click event in there.
For the sake of example lets call the method btnAuto
In the button click event:

thisform.btnAuto

In the form init event just put the same code
This will fire the code when the form loads

 

[Dan Freeman]

Yes, that should do it.

Are you getting an error message? Is smoke shooting out of your speakers? What?

 

[Mike Lewis]

The problem with _Screen.ActiveForm is that the form in question might not be the active form at the time that you need to execute the code.

I would strongly recommend that you stop pursuing this, and instead re-organise your code so that you don't need to call the Click method from outside the form. Even if you did get it to work, it's bad design, and will trip you up sooner or later.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[JRB-Bldr]

Let's see....

Back in your question: thread184-1672752
we suggested that you change your over-all data table architecture.

Now we are suggesting that you re-organise your code.

Maybe you might want to consider starting the whole project over with a totally different approach in most development areas so that you didn't encounter so many challenges primarily based on poor over-all design.

Good Luck,
JRB-Bldr

 

[thegame8311]

Well I think since I originally did this using php and mysql, that was a bit more organized, and being new to VFP, I was trying to keep the same strategy, but that was a bit much also.

Unfortunately the way I was trying to work this entire idea out was by trying things and discovering what works, the organization of it was not as thought out yet, as this is far from a complete project.

I do appreciate everyone leading me in the right direction

 

[JRB-Bldr]

We applaud your efforts to learn VFP, but keep in mind that changing from Language A to Language B where the language itself and its capabilities might dictate a LOT of major approach differences, should probably be taken into consideration prior to launching an application development project.

The analogy that I like to use is that it would be like attempting to translate a book written in Chinese to English (or vise-versa) where NOTHING can be a one-to-one translation and even the basics have to be approached quite differently.

By attempting to follow the same strategy used previously your numerous questions suggest that it has led you into a number of self-imposed challenges due to the development approach used.

Forgive the repetition, but if you want to learn VFP, you need to start at the basics of data-centric VFP development and build up from there.

Starting from a less-than-optimal development strategy will build a very shaky foundation off of which to learn VFP for future development projects.

Sure by getting your numerous questions answered in Tek-Tips you will have learned how to get around a number of the specific challenges you have encountered, but will it have gotten you to the point of understanding how to approach the next VFP development project?

Regardless - Good Luck,
JRB-Bldr

 

[thegame8311]

I think there is something in the tutorials that will help with this, thanks

 

[AlastairP]

From the perspective of a fellow newcomer to VFP:
I agree the with excellent advice you have been given.
I restarted my app a couple of times from stratch as I realized that the approach taken would create more problems later.

I would recomemd you have a look at Garfield Hudson's web site and watch his videos.
There is a large amount of information in the free section and some great stuff in the member section.

Regards

Alastair

 

[Mike Gagnon]

Tamar,

Interesting you mentionned. I never program click events right into the form, always outside in a prg. That way I can always re-use the form, and just change the click event according to the needs of the particular form.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[TamarGranor]

Interesting you mentionned. I never program click events right into the form, always outside in a prg. That way I can always re-use the form, and just change the click event according to the needs of the particular form.

But that breaks encapsulation and makes the form depend on something else existing.

Now, I don't think you should put more than a few lines of code right into a Click method either. Click should call a method (most likely, of the form) that does whatever you need to. So the Save button calls ThisForm.Save(), and so forth.

Tamar

 

[Olaf Doschke]

In the meaning of the original poster, first of all: Calling an event is a wrong idea. calling it from a PRG even more so a strange need.

If the code does something that should be done upon request by the user (through a click) and programmatically, too, then it belongs into a form method or even better into a seperate class the form uses.

Actually I do have nonvisual business classes using data access classes and also encapsulating functionality you do on that data, indeed ideally it encapsualtes all functionality done on a certain group of tables.

This way such a "domain" of the application handling several tables is one module I can add to many forms of that domain.

Sometimes each form will have it's own instance of such a class. But for collaboration forms can also share one instance of that business layer class (obviously also shareing a datasession).

By the way: The dataenvironment class and cursoradapters are nice base classes for this.

And these business classes could also be used from without GUI, so all the form does is display data and enable editing to the user on the one side, and calling methods of that business classes on the other side.

GUI methods should rather only care for GUI, not for anything you need to call from outside of the form.

A save method, like Tamar gives as an example, is ok. It's a bit in the gray zone, but it's very fine to make some checks and move control values eg of unbound controls into cursors. Next step is calling save of the business object, which forwards this to the individual data access objects.

It's asked much to change to this kind of class design, but take the idea of encapsulation and seperation of concerns. More seperate code means more maintainance, but independant maintainance and more concrete tasks. And you can generically solve things, so there is few things to do for each table.

Bye, Olaf.

 

[Mike Gagnon]

Tamar

Yes it does break the encapsulation, but it makes it easier to build the methods into a COM+ dll, and have them run server-side, rather than client-side.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[TamarGranor]

Sounds like something that I'd do by having a class that contains the necessary code, and instantiate it in the form.

Tamar