Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Release Form From Within Load Event?
- Thread starter Shanachie
- Start date
HI
Put in the Init event of the form
RETURN .F
The form will get released.
____________________________________________
ramani - (Subramanian.G)
When you ask VFP questions, please add VFP version.
Put in the Init event of the form
RETURN .F
The form will get released.
____________________________________________
ramani - (Subramanian.G)
When you ask VFP questions, please add VFP version.
- Thread starter
- #3
Actually, you can also return .F. from the Load method to prevent the form from instantiating.
-BP
-BP
Hi
There has to be some purpose in calling a form. The forms objects will get initialised only after the load events.
You could call some contained objects methods, after their respective inits. So doing such initialisation and then calling some events, and then checking if some values are this way or that way, then based on those results you will be calling to release the form or continue it. That is the reason, I suggested to return .f. from init event.
If the only purpose is to run the code in load of a form, then, better that code can be run from a procedure or function. So even if Load will return .f. and technically
will release the form, I did not suggest that.
____________________________________________
ramani - (Subramanian.G)
When you ask VFP questions, please add VFP version.
There has to be some purpose in calling a form. The forms objects will get initialised only after the load events.
You could call some contained objects methods, after their respective inits. So doing such initialisation and then calling some events, and then checking if some values are this way or that way, then based on those results you will be calling to release the form or continue it. That is the reason, I suggested to return .f. from init event.
If the only purpose is to run the code in load of a form, then, better that code can be run from a procedure or function. So even if Load will return .f. and technically
will release the form, I did not suggest that.
____________________________________________
ramani - (Subramanian.G)
When you ask VFP questions, please add VFP version.
- Thread starter
- #6
The form in question displays the contents of a purchase order. The Load event checks to see if the PO is new, i.e., whether to create it. (PO# = 0 => create) The Load event calls Procedure NewPO if needed to create a record in the PO table, changing the PO# to > 0. Then the Load event opens the PO table to the correct PO, new or not.
Under some extremely rare circumstances, NewPO may not be able to create a PO at the time. The new PO# is assigned by finding the biggest PO# currently in the table, locking that record, adding one to the PO#, inserting the new record, and unlocking the locked record. If another user tries to create another PO at the precisely correct moment, their attempt to lock will fail. (Maybe it's the precisely wrong moment? <g>) In that case, the PO# still = 0 so I display a message to the user, and do not open the PO form. The circumstances are obscure and have happened only twice in seven years that I'm aware of. (Over 50,000 POs have been created on this system during that time.)
It is true that I could create a procedure that does NewPO and OpenPO and then does form PurchaseOrder. But before I saw the need for this I wrote the code in the Load event. In the spirit of "don't mess with it more than you need to" I just wanted to modify the Load event.
That's the long story.
Thanks for your input,
Shanachie
Under some extremely rare circumstances, NewPO may not be able to create a PO at the time. The new PO# is assigned by finding the biggest PO# currently in the table, locking that record, adding one to the PO#, inserting the new record, and unlocking the locked record. If another user tries to create another PO at the precisely correct moment, their attempt to lock will fail. (Maybe it's the precisely wrong moment? <g>) In that case, the PO# still = 0 so I display a message to the user, and do not open the PO form. The circumstances are obscure and have happened only twice in seven years that I'm aware of. (Over 50,000 POs have been created on this system during that time.)
It is true that I could create a procedure that does NewPO and OpenPO and then does form PurchaseOrder. But before I saw the need for this I wrote the code in the Load event. In the spirit of "don't mess with it more than you need to" I just wanted to modify the Load event.
That's the long story.
Thanks for your input,
Shanachie
satyenshanker
Programmer
You could do the same in the load event too.
Satyen
Satyen
Hi Ramani,
If the only purpose is to run the code in load of a form, then, better that code can be run from a procedure or function. So even if Load will return .f. and technically
will release the form, I did not suggest that.
I can think of other reasons to return .F. from the Load. <g> A case I've had recently was for a Tool Inventory system. You have to define tools in the Tool Master screen to set things up. The Transfers screen will check if you have have anything in the ToolMaster table. If not, I display a MESSAGEBOX that you need to setup tools first and then I just return .F. from the Load.
-BP
If the only purpose is to run the code in load of a form, then, better that code can be run from a procedure or function. So even if Load will return .f. and technically
will release the form, I did not suggest that.
I can think of other reasons to return .F. from the Load. <g> A case I've had recently was for a Tool Inventory system. You have to define tools in the Tool Master screen to set things up. The Transfers screen will check if you have have anything in the ToolMaster table. If not, I display a MESSAGEBOX that you need to setup tools first and then I just return .F. from the Load.
-BP
- Status
Similar threads
