return to previous window

[Cheryl Lemire]

The following will return me to the previous record in the current query:

parentform.fetch_previous()

Is there a 'previous' command that I can use to return to the previous window? Example, I am on a data entry form and click a button that closes the form and brings me to another form. I would like to be able to leave my new form and return to the last form I was on.

I know that I can leave the original form open when going to the second one and then just close my second form, however, I may not always want to return to that original form so I would prefer not to keep it open.

[Jerry Gray]

RE: return to previous window

Cheryl,

This is a good thread about a similar topic:

http://msgboard.alphasoftware.com/alphaphorum/read.php3?sortby=lastreply&direction=desc&num=11&id=66386&thread=66366

Later,
Jerry Gray

[Cheryl Lemire]

RE: return to previous window

OK, does this make sense?

OnExit Event of the form

1. retrieve current layout name
2. assign value to global variable
3. close current form

OnPush Event of Return to Previous Form Button

Assign layout global variable to layout_name of which form to open

[Pat Bremkamp]

RE: return to previous window

Cheryl,

I used to have code in one of my apps to do this, but it turned out to be more trouble than it was worth. Anyhow, once the number of windows gets greater than 2, it requires some work.

I don't have the code anymore, but here is what I did.

In the autoexec, create an array variable, say winder[1], and set winder[1] = your main menu name.

When you open another window, set winder[2] = that window name, and so on.

Now, you have to decide if the same window will ever be open more than once...if so you may have to modify the next steps.

Then, when you close a window, search the array for the window name, find the previous window name, and check if it is still open. If so, activate it. If not, open it.

Then, if you want to move forward, keep the closed window in the array, and if not, delete the name in the array.

As I said, I had all that working, but ended up taking it out when I decided it was easier just to click on the window I wanted.

Good luck,
Pat

[Cheryl Lemire]

RE: return to previous window

For the application that I am working on we are only concerned with being able to return to the previous window for one form so arrays etc will not be needed. The users will have the option to return to the main menu from every form so they can navigate as needed. This is what I ended up doing:

1) I wrote a script to return to the previous window which uses a global variable for the form name.
2) I created a custom toolbar and one of the buttons on that toolbar is to return to the previous window which runs the script that I created above.
3) I have declared the global variable in the autoexec script.
4) In the OnExit event of the forms I have the following code:

'Retrieve current form layout name
'Assign value to global variable vcgFormLayout

vcgFormLayout = topparent.name()

Hopefully this will help somebody else in the future. The code for my return to previous window is at the end of this message.

Cheryl

'Date Created: 21-Sep-2004 12:07:50 PM
'Last Updated: 21-Sep-2004 12:16:35 PM
'Created By : Cheryl Lemire
'Updated By : Cheryl Lemire
'Return to Previous Window

DIM Shared varP_window as P
DIM layout_name as c
layout_name = vcgFormLayout
DIM tempP as p
'Get pointer to existing window. In case layout_name is qualified with a dictionary name, extract up to first @. In case formname has spaces, normalize it
tempP=obj(":"+object_Name_normalize(word(layout_name,1,"@")))
'Test if pointer is valid
if is_object(tempP) then
'Test if pointer refers to a form or browse
if tempP.class() = "form" .or. tempP.class() = "browse" then
'If so, then activate the already open window
tempP.activate()

else
'Window is not already open, so open it
varP_window = :Form.view(layout_name)


end if
else
varP_window = :Form.view(layout_name)

end if

'Close the current window.
'check that you are in a window
if is_object(topparent.this) then
topparent.close(.f.)
end if

[Cheryl Lemire]

RE: return to previous window

I forgot to add, if anybody has an easier way to accomplish this I am always open to suggestions.

Also, as part of the 'easier way' to accomplish this, in the above:

4) In the OnExit event of the forms I have the following code:

'Retrieve current form layout name
'Assign value to global variable vcgFormLayout

vcgFormLayout = topparent.name()

I would prefer to put something in my autoexec script that will assign a value to the global variable so that I can avoid having to place code in the OnExit event of all forms. The problem being when running the autoexec I do not yet have a form open so the above code would not work for that.

Any ideas?

[martinwcole]

RE: return to previous window

Cheryl, unless I am mistaken, all you have to do is just close the form - and you will alwys go back to the last form

like log on to mastermenu
pick clients
in clients pick invoices
in invoices pick details
as you close details you will return to invoices - from invoices to clients - from clients to mastermenu

also, unless you want to permit two instances of the same form/window, in all your buttons and so forth where you open a form, be sure that you check to see if it already exists/is oalready open, and if so, just show and activate it

in xbasic:
if is_object("someform")
:someform.show()
:someform.activate
else
form.view("someform")
end if

[Cheryl Lemire]

RE: return to previous window

Thanks for the input Martin. I am closing all forms when going to a new form so the previous form will not be there if I just close the current form (unless I am misunderstanding you and Alpha automatically re-opens the last form if no forms are open?)

My Return to Previous Window script is checking to see if the form is already open. This should never be the case but I do have it in there, just in case I have forgotten to close a form along the way.

I also plan on adding error handling which I have not yet done. Any other ideas or suggestions are always welcome and appreciated.

[martinwcole]

RE: return to previous window

Although I haven't used it, I recall seeing a "navigator" in V5 - where it displays a little form that would be a menu form all available forms - that way you could give the user the ability to quickly choose where they want to go.

[Tom Cone Jr]

RE: return to previous window

Cheryl,

This approach is going to take a lot of work. In addition to the form name, you probably will want to capture the current sort sequence, and the current index or query list, and possibly the current record number. When returning to a 'previous' form these will need to be restored in order to give the user a sense of 'returning'.

Many of us leave forms open as we open new forms. When the new form is closed we're returned to the first form automatically. The context in that form never changes.

-- tom

[Cheryl Lemire]

RE: return to previous window

Thanks again for the input. I have been in the habit of closing all forms when going to another form with a few exceptions. I do not see the benefits of leaving forms open all over the place, especially if the user will be travelling to a lot of forms throughout their work. Can you help to explain the benefits of not closing forms as you go along?

As far as capturing additional information, I guess I need to think a little deeper on the actual use of the application. Even from data entry forms, if the user is wanting to return I am thinking that they simply will be returning to enter a new record so I am not sure it is necessary to capture anything beyond the form name itself.

If they are leaving a query based form I would think they would want to start fresh and not from a last query run. There will also be a lot of menus throughout the application that the user may be returning to which I do not believe would need any additional trapping. What am I missing?

[Cheryl Lemire]

RE: return to previous window

fyi, I changed the code from the OnExit event to the OnEnter event of the form and am now using the following:

'Retrieve current form layout name
'Assign value to global variable varForm

vcgFormLayout = this.name()

Thanks Tom

[Cheryl Lemire]

RE: return to previous window

Correction, this did NOT work with the OnEnter event or the OnActivate event. I had to place the code in the OnInit event of the form in order to capture the form name.

[CALocklin]

RE: return to previous window

Can you help to explain the benefits of not closing forms as you go along? Not really but it might be an interesting discussion. Maybe I can explain why I do it and you can explain your logic? Like many things, I'm sure there are benefits to both methods.

Generally, my applications are basically menu driven and I do not allow users to run windowed. This means that they can only go from the form they are currently using to either the previous form (by closing the current one) or to another form for which I have provided a button or other action. I know that others like to provide windowed apps but I feel that this allows users too much chance to do something that I had not expected and, therefore, not planned for. (They do that often enough anyway so I prefer to minimize the potential problems.)

What this means is that, in most cases, there will seldom be more than 2 input forms open at any one time and seldom more than 2 menu forms open. For example, Main_Menu -> Support_Files_Menu -> Sign_Types_Form. If they want to do something else, they must close the form(s) and navigate through the menus as necessary.

When building an app for myself, I will sometimes make it a windowed app because I know I won't yell at myself too long when I do something wrong. (I may feel pretty stupid but at least I won't waste my own time telling me how much trouble it caused and asking how to fix it and why I can't make the application completely foolproof so mistakes like that can't be made by users who don't know what they are doing.)

Of course, someone could make the argument that I can add buttons on each form to go to any other form BUT what do I do when there are 100 forms? Create one small button for each form thus leaving no space for real data? That would be ridiculous so why not build a dialog to let the user select the desired form? Wait a minute - isn't that about the same as going back to a menu? Besides, how does the user choose between the Inv_Spec_Cmnts form and the ones named Invoice_form, Invoice_form_lg, Invoice_payments, Invoice_payments_lg, Invoices_by_wo, Pre_inv_review, and Wo_inv_review? The actual choice of the correct form will depend on the starting point and what the user is trying to do. Besides, I believe button text can be much more descriptive if necessary.

Another choice would be for me to select a subset of forms that could be accessed from the current form but in many cases that is very much the same as going back to the menus.

Having said all the above, please note that I did say that there "will seldom be more than 2 input forms open at any one time." In some cases there can be many more than that but it is a rare situation. For example, there is one app that allows the user to open the Master_Order form then the Close_Orders form and then the View_Work_Order form which actually allows them to go to the View_Master_Order form from which they can go to the Client_Input form and then to the View_Signs_Installed form. However, they normally don't go beyond the 3rd form (View_Work_Order) just to verify something before closing the order.

The real issue in that last case is that I had to make sure the users couldn't circle around on themselves and get back to the original form because that could mean that the original job never gets finished. The users of this particular app have so many interruptions that it would be entirely possible for them to get back to the original form and switch records without ever realizing that the record they were originally working on never got closed.

In other words, I feel that this method reduces the complexity of the app and minimizes the chances for user errors. Yes, in some cases it means one or two extra mouse clicks to get where you want to go but if it only happens occasionally then it's no big deal. When it becomes a regular thing then I consider adding a new button to the form if it seems appropriate and logical.

Cal Locklin
www.aimsdc.net

[martinwcole]

RE: return to previous window

I strongly ditto Cal's ideas.

Although I will add this - if you are making an app for storing recipes, it probably won't make much difference.

But my experience is that if you are designing a business app for a client, especially where there are varied levels of savvy among users, unless you totally control where they can go - disaster will happen. Its not a question of "if" - its a question of "when."

Lets take a practical example: The client goes to clients from a set, to [enter invoices], begins entering an invoice - notices that the address is not what she likes - opens clients again, and starts editing the client - leaves the client open - gets a call on the phone - goes back to clients again - enters an invoice - notices that the line item is mispelled, opens line items in a form based on the table - not the set, and starts editing the line item and somewhere along the way she starts getting locked file error messages - and can't figure out what to do.

At that point, if she hasn't damaged the data, she may have several copies open, and unless she calls you and you log on and figure it out, she may have to restart her computer, as she doesn't know how to recover otherwise. And will almost certainly have a partially completed record left over that may wreak havoc for you in some of your reports, etc.

But if you tightly control what she can do, by leaving every form open as you logically progress forward, then she will always go back to where she should be when she closes.


Reminds me of a funny story - many years ago I was developing an app that would run on many computers in many different cities, and by a verrrry varied level of savvy users, to put it mildly. A scenario somewhat similar to the one I described happened. The office called the Main Office, and the Main Office called me. I investigated, and reported back that it was operator error. My client responds, "Martin, I am paying you a lot of money to develop an app that will work - I don't care "why" it failed - fix it so that it "can't" fail.

Anyway - from that point forward, I try to develop apps that are bullet proof, excepting that they type in the wrong name! Although over the last 20 years we have gradually gotten an increasingly more savvy set of users out there, and certainly in the next 10 years or so that will become increasingly true, there are still a lot of users out there that will get hired to use the app that have never used a computer before.