How to go to previous Window?

[djlane]

Is there an FM8 function which will allow me to move back to the previous window? ie. to be able to go to the last / previous active window, without having to specify that previous window by name. Something like the "Back" button in Internet Explorer.

I can do it by having a separate table called "last window name" to hold the name of the current window before navigating to the second window, thus allowing me to go back to window I last came from.

But this is tedious. Is there a simpler way?

thanks

[Inky Phil]

Well if the windows are from the same table you could use a global variable to store the last window and if they are from the same file you can use a global field.

Whether either of these options are any better for you depends,I suppose, on which bit of your method you regard as 'tedious'

Phil

[djlane]

OK, so Filemaker does not have a function to do this.

Actually, these windows are separate files.

What I meant by tedious was that I did not wish to have to do a workaround if FM8 already had a built-in function to do it. Apparently it doesn't.

So this is what I plan to do, perhaps you might suggest a cleverer way..

Create a new File called "last window name" with two fields. A global field to hold the name of the last window, and a global field to relate the file to every other file.

In every other file I also have a global field to store the last window name, and a global field to relate that file to the "last window name" file.

If I want to move from my orders file to a customer file (eg go to related record(s), I first save the current window name in orders::last window name , and then run an external script in the "last window name" file which sets the global field there to the value in orders::last window name.

When I wish to return to the orders file, I run a scriot in the "last Window name" file to select the window stored in the last window name global field.

I consider this tedious because for every file I navigate from I have to have a script in the "last window name" file, and I have to relate that file to all my files as well.

The "back" button is a pretty common feature, I'm surprised its not a standard function.

Thanks

david

[Inky Phil]

I think it can be a lot less tedious than that

Why not just have 1 record with 1 field in your 'memory' table. This is the field where you will store your last window data.

You can now create a cartesian (x) relationship from any other table using that same field as the child key.

From wherever you are then all that you will need is 1 set field as you are going out (to store the windowname) and one set field as you are coming back in to get the windowname

HTH

Phil

ps just in case you are not aware of them a cartesian relationship is one where any field can match any field and they can be used to replace the old 'constant' type relationships. Just select x from the options instead of =

[djlane]

Aha. A cartesian relationship. Never heard of it! Its not even mentioned in FM Help! But I have now found it in a 3rd party FM book.

Thanks!

david

[Inky Phil]

Inky Phil - Reducing tedium on a world wide basis! ;)

[Genx]

To go to the last active window, try ctrl + shift + tab

[Inky Phil]

Ah.. Genx, How I envy you the innocence of youth.

Your option might seem easy but you have missed the whole ethos behind this discussion.

I would wager that an overwhelming majority of users, given that they were used to one click of a button, if faced with a 3 simultaneous keystrokes option would gasp aloud, as one, 'How Tedious!'

Phil :party:

[Søren Dyhr]

A cartesian relationship. Never heard of it! Its not even mentioned in FM Help!

Wrong it's mentioned here:

http://www.filemaker.com/help/07-Related%20files8.html

...last line in the box, although the phrase not directly is mentioned!

OK, so Filemaker does not have a function to do this.

I think you are using a wrong metaphor when dealing with filemaker, we consider it a development tool, not a final solution - and since the use of multiple windows is a developer choise, should you feature request be regarded as an option to an option ...such demands is probably comming from chewing a corner of an elephant, similar to expressions like...

http://en.wikipedia.org/wiki/Not_Invented_Here

How would you overload unwanted features of such a command? Somethings needs some tinkering - when dealing with a developement tool.

The option I see in front of me with your question, is to get rid of all the windows, this is probably a migrated solution with the artifacts mentioned, but tools exists to deal with such unifying matters it only depends on what version of filemaker you're on.

If it isn't included reachout for thirdparty tools to do it. FMRobot comes to mind. Try to study the Separation Model threads here and learn that other ways of slicing your data into files exists.

--sd

[Genx]

Lol, i just read the topic title, the first post and skimmed through the others... Nevermind then.

[djlane]

Soren,

Sorry, but I do not agree that a feature which brings you to the previous window you viewed is something that could be described as "overloading (with) unwanted features".

There are many many functions in FM for which I have no use. By your logic then, I should consider that because they are superfluous to my personal use, or because I can find a workaround, I should consider them as feature overload.

Yes I may be just chewing on the corner of an elephant, that is why I use this forum - to expand my knowledge. I come and look here when I get stuck with something or when I feel that I may be making work for myself by doing something in a longer way than necessary.

Not everybody knows (or cares to know) as much about FM as you do, but there are many people who use this forum who are happy to help less experienced users without smart-ass comments.

have a nice day

[Søren Dyhr]

There are many many functions in FM for which I have no use. By your logic then, I should consider that because they are superfluous to my personal use, or because I can find a workaround, I should consider them as feature overload.

I thought somewhere along the lines that you had some object oriented... bagage, but I assumed apparently wrong. Overload is to use most of an objects virtues, and then rewrite something that ushers itself into getting the first call's instead.

There are many many functions in FM for which I have no use

How can you be sure have enough to dismiss or reject them on?? It's pretty easy to think a tool out of it's realm, it's much harder to get the gist of each piece of tool ...enough to pick the right one every time.

I remember once I read an article of a journalist who attempted a famous painters painting course in Spain, where the participants were set to paint landscapes. Our journalist felt himself strugling immensely with the brushes and got the bright idea to make abstract paintings instead - the famous painter noticed this, asked teasingly if it was any easier.

Nothing is achieved when trying to redesign the framework, when what it takes is the hard work get used to the way the tool behaves.

--sd