J Wise wrote: > >Would using the calling form's tag property be an okay >place to store this info. Setting it to either 1 or 2 >by the subsequent form and then checking its value >when focus returns to the calling form??? >
Exactly what I was thinking when I assumed that the knowledge of which form last called form3 had to be maintained in one place; 1) a global var LastFrmTag in the parent or main unit 2) an If Then Else statement (or a case statement) in a function in the main unit which is called by the OnClose event in the child or temporary form. 3) the called function receives the tag value of form being closed and it is passed to the var LastFrmTag. 4) the Menu system or main loop of the main unit executes the next instructions based on the value in LastFrmTag. This is not what's called for, the design implies that form3 does the task of maintaining the information and returns control to the form that called it. Form3 is closed during the application run so it's global vars go out of scope. The answer is; Every form that calls form3 passes it's own tag value to form3.tag, and form3 calls form1 or form2 based on what the value of it's tag is. This implies that there is a unique integer assigned to every forms tag value at design time. If the application contains more than 10 or 12 forms this starts to become a maintenance headache. Also, if you get to a point where you have many forms you will usually find that you have a number of forms where the actions on the closing of the form is very similar to that closing another form. Looking further down this tunnel it's plain that you will have to look at every forms OnOpen and Onclose event to review the effect of changes made when adding a new form to the project. This means a table that identifies the form ID numbers is important to have as a document. You could also design it so that forms which carry out activity X have tag range 0-99 and activity Y have range 100-199. Unless it's required for design purposes there is no need to assign the forms unique tag id's. When you get to the point where more information about the state of your application needs to be maintained then you have to think about larger objects. In the case where identifying the last form is the only requirement, the tag value serves well as a 'last caller' flag, but it adds design overhead in terms of documentation maintenance. Now if you want to get really fancy I remember an app that used tag values as a parameter that was converted to binary and the receiving form converted the binary to a series of true or false values which set up checkbox values for the form during the onShow event. That's all for now :) B ------------------------ Yahoo! Groups Sponsor --------------------~--> <font face=arial size=-1><a href="http://us.ard.yahoo.com/SIG=12h4r5b5f/M=362131.6882499.7825260.1510227/D=groups/S=1705115362:TM/Y=YAHOO/EXP=1124066907/A=2889191/R=0/SIG=10r90krvo/*http://www.thebeehive.org ">Get Bzzzy! (real tools to help you find a job) Welcome to the Sweet Life - brought to you by One Economy</a>.</font> --------------------------------------------------------------------~-> ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [EMAIL PROTECTED] Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/delphi-en/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
