classes with forms - how to instantiate a form in a class from a form in a class

[DrAlbany]

Hi Guys..,

Hope you can help.

Visual foxpro 9

Background: I run a small IT company selling hardware and web hosting. I want to import different suppliers data feeds (products and pricing) into a temp table and then scan my stock files and change supplier prices and stock levels as needed, add new stock and flag my stock as no longer in my suppliers list. I also want to import supplier data feeds and convert that data to something that is suitable for importing to ecommerce websites - my own website and customers.

I have created the import program all works fine for my own use. So I then started to create the ecommerce program that I could give to my customer to allow them to manage their own data feeds... (the import routine allows you to configure the fields needed for different types of supplier and map those to your own tables.

So, no point in reinventing / modifying the data import program again so I decided to experiment with classes etc...

I've created a class... acsimport which when the "import_main" screen is instantiated it check's if the data tables exist and creates them if needed... (I thought if i can implement all of the data creation in the main screen I could drop the class in any project and wouldn't have to remember to make sure all of the data tables where in the correct place... the "import_main" form would create the tables if they didn't exit and offer a menu to configure the import routines.

So... i'm new to classes etc.. and to experiment I and have added only two forms to the class...

Now I'm lost as to what to search for in google to try and find a solution... so I was hoping you may be able to help.

I have created a normal form with a button and the following code executes when you press the button:-

SET CLASSLIB TO acsimport additive

oMyForm = CREATEOBJ('import_main_menu')

PUBLIC a

a = oMyForm

oMyForm.show()

Again... this is just so I can experiment...

It works and calls the form within the class... "import_main"

Import_main has 2 buttons... one to close the form and one to goto another form to start the configuration process...

To start a normal form I would just do:-

DO FORM forms\import_master_list

and it would launch...

So, Whats the best way to start the other forms from the class?

I assume I need to do as I did with the original form and "oMyForm = CREATEOBJ('import_main_menu')" etc...

But is this the correct way or am I missing something?

Thanks in advance.

Regards

Steve



If you alway do what you've always done, you always get what you've always got.

 

[Olaf Doschke]

Why don't you try and come with any problems you might have?

I can think of a problem you may have - yes - a problem addressed just very recently by Mike Lewis in thread184-1751915

He talks about DO FORM ... NAME oForm, which is essentially the way to start an SCX with a form object reference in a variable named oForm, which you normally only need with CREATEOBJECT.
The catch is, as he says: The object reference (oForm in this example) needs to remain in scope while SecondForm is active.

If you switch to use of form classes you can go into two camps: Some handle form classes as "abstract" classes, classes you don't use themselves, but you inherit from. You can create SCX forms based on a class. The advantage is handling forms the way you are used to and still profit from inheriting, the downside is, you can't easily continue inheriting from your final SCX form and continue the inheritance line.

The other camp is using some mechanism to keep forms alive via a form manager. I'm in that camp. One simple way to professionally handle form references without making use of public variables is adding them to a collection.

Simplest use case:

*somewhere in main.prg
_screen.Addobject("oForms","collection")

Later usage of this can be this way:

_screen.oForms.Add(CREATEOBJ('import_main_menu'))

You neither need a variable nor a public one. Anyway, it makes sense to have a reference, if it's just to show the form:

oForm = CREATEOBJ('import_main_menu')
_screen.oForms.Add(oForm)
oForm.Show()

This has a nice feature: It keeps forms alive wthout hindering you to close them, to be more precise, it's a feature of the collection class.

The code can even be simpler, if you have one base form class all other classes inherit from, then you can put this in the baseform init:
[pre]_screen.oForms.Add(This)[/pre] And your form creation then does not need to add the form reference, this is done by the form itself.

If you don't use the base collection class, but subclass it as your own class, you may use it as any object repository and handle things like preventing double instances or other features. If you store references with a key you can of course easily get an object reference from the collection.

Bye, Olaf.

 

[DrAlbany]

Many thanks Olaf..,

Makes perfect sense now

I knew their must be a way without using public variables... it just never clicked in my mind Sometimes we got too close to a problem... a bit like not seeing the forest for the tree's

Once again, many thanks.

Regards

Steve



If you alway do what you've always done, you always get what you've always got.

 

[Olaf Doschke]

Hi Steve,

FYI: Before we had the collection FoxPro frameworks offered form handlers storing form references in arrays or in properties.

The funny thing is, the _SCREEN already has a form array _SCREEN.Forms and some frameworks iterate it to close all open forms at application exit, but this native _SCREEN object array is no real vfp array and does not count to the number of references keeping objects or forms open, eg a createobject("form") adds a form there, too, and increments _screen.FormCount, but that doesn't halt the form from vanishing, if the reference isn't persisted in any other variable or property. Also the reference in _screen.activeform doesn't contribute to the object reference counter.

Bye, Olaf.

 

[DrAlbany]

Thanks Olaf..,

So what is the best method for keeping the form active? without using public variables?

Regards

Steve

If you alway do what you've always done, you always get what you've always got.

 

[Olaf Doschke]

Steve?

>So what is the best method for keeping the form active? without using public variables?
I already told you.

In my sample code oForm is not public, it will release and still the form will stay, as oForms value - the form reference - is stored into the collection.

Bye, Olaf.

 

[DrAlbany]

Thanks again Olaf..,

Sorted it

After reading a great article on [URL unfurl="true"]http://www.tomorrowssolutionsllc.com/[/url] regarding containers... it all sank into place

Regards

Steve

If you alway do what you've always done, you always get what you've always got.

 

[Olaf Doschke]

What do containers have to do with it?

Bye, Olaf.