Hans L


Situation:

I am in a form A, click on a cmd, and it opens another form B and hides the current form A.

In form B, I click on a cmd and I would like to show form A and release form B.

The release of form B works, of course, but not the showing of form A. I have never seen anything about whether it is possible to make changes in or affect one form from another. Is it (I guess it would work with a form set )

Hans L



Re: Showing one form from another

Alex Feldstein


You can do it by taking a reference to the other form.

See DO FORM command in help:

DO FORM FormName |  [NAME VarName [LINKED]] [WITH cParameterList]
  [TO VarName] [NOREAD] [NOSHOW]

Do Form formB NAME oFormB LINKED

then in the form you can reference anything (properties and methods) of the other form.

oFormB.Release()

 






Re: Showing one form from another

AndyKr

>> I have never seen anything about whether it is possible to make changes in or affect one form from another.

Yes it is possible - take a look at the article on my WebLog: - "Getting a reference to a parent form" at http://weblogs.foxite.com/andykramek/archive/2005/09/04/899.aspx

>> I guess it would work with a form set

Forget form sets, now immediately and forever! Their primary function was for converting FoxPro 2.6w "Screen Sets" and they carry a lot of baggage that is related specifically to FP2.6 and is irrelevant in VFP. There is nothing that you can do (other than mimic READ MODAL - a long-dead and irrelevant technique) in a formset that cannot be done with object references and _Screen. That also happens to be a much better way of doing it....








Re: Showing one form from another

Hans L

Thanks, Alex and Andy. Funny, I actually tried _Screen as a "container" for forms, but it did not work the way I did it. I'll check the reference stuff.

I would like to follow up with the issue that is at the bottom of my original question. If one does not want to leave form A visible under form B, is there any consensus what is better: closing *or* hiding form A when one opens form B




Re: Showing one form from another

CetinBasoz

It might be better to close formA, show formB and when done do form formA again from start (I suggest design your forms with private datasessions and loosely coupled - that's each form could be ran and tested individually to the possible extent). However it all depends on your needs and sometimes might be better to keep formA open and hidden. Assuming you would want to do that for any reason (ie: called form needs to access caller form) here is a simple outline:

*formA

do form formB with thisform && passes its reference
thisform.Hide() && hides itself

*formB.init
lparameters toCaller
this.Addproperty("oCaller", toCaller) && save whatever the passed parameter is - might be that no parameter is passed

*formB.release
if type( "this.oCaller" ) = "O" and !isnull( this.oCaller ) and lower(this.oCaller.baseclass) == "form" && forget about formsets from the start
this.oCaller.Show()
endif





Re: Showing one form from another

Hans L

Thank, Cetin. I will try both releasing and hiding and see how it works out.




Re: Showing one form from another

AndyKr

>> If one does not want to leave form A visible under form B, is there any consensus what is better: closing *or* hiding form A when one opens form B

Despite what Cetin said, I think It is really a matter of what the forms are doing. If your user has just spent 20 minutes finding the correct record and has called form B because they want to check some unrelated pice of information, they probably wouldn't thank you for closing A and losing all their work. Similarly, if "A" is an editing form and has uncommitted changes you wouldn't want to close it and if the user might need to look at something in "A" while working in "B" it would be better to leave it open AND visible (which is the normal behavior of forms in a Windows application anyway).

So, as usual, the answer is that "it depends on what you are doing". For what it's worth, my personal preference is that I rarely hide or remove things that the user has opened in my applications. After all, it is the user's environment, not mine, and if they want to close or minimize a form they can do so. I really don't like applications that do things 'for me', unasked.






Re: Showing one form from another

Hans L

Makes sense in general. In my case, many of my apps will be of the kind that you click on a main menu, get a list of, say, individuals (friends, relatives, etc.), then click on the record you want to see details of. No need, in my view, to have the first window (the list) open. But as I get further into this, I may change my mind. If one needs to check another persons' details, one should be able to get back to the list and select that other person's detail screen, and check it out without closing the first person's screen.

I have been "conservative" in the past mostly because of lack of knowledge how to deal with multiple open screens. As I think it through and manage it, I will probably gravitate towards letting the user decide what to close and what not to close.




Re: Showing one form from another

AndyKr

>In my case, many of my apps will be of the kind that you click on a main menu, get a list of, say, individuals (friends, relatives, etc.), then click on the record you want to see details of.

Just on thought, this type of interface is fine in VFP but does not scale well and can be cumbersome if the tables are large - scrolling through thousands of records in lists gets very tedious, very quickly.

It is generally better to use some sort of 'find' screen that retrieves just one record (or maybe a few possible candidates) at a time.






Re: Showing one form from another

Hans L

Well, when it comes to names (individuals), for instance, I will be able to sort on both last and first names (I very often remember only one of them). In addition, I intend to create incremental search, that is, you press "L", and you get down to the "L" people, and then you press "e", and you get to the "Le" people, etc. However, a search window might be better in some instances, searching in a list of dates, perhaps. I understand that there are incremental search sample code available. Maybe even for the search window. And, as you mentioned, if you want only a subset (one or more records), a search window is needed. Well, you just talked me into it :-)




Re: Showing one form from another

AndyKr

>> In addition, I intend to create incremental search, that is, you press "L", and you get down to the "L" people, and then you press "e", and you get to the "Le" people, etc.

See KiloFox Chapter 4 there is an Incremental search text box class there (Example: CH04.VCX::txtSearch ) which should make things a little easier for you

>> Well, you just talked me into it :-)

LOL! I didn't mean to re-design your whole app for you






Re: Showing one form from another

Hans L

"LOL! I didn't mean to re-design your whole app for you"

Well, I don't want to kiss a-s, but hey, I couldn't think of anyone better :-)