Also, I'm using FMPA on a Mac if that makes any difference. Any help would be great!
This post says "solved" but I can't see the solution, I would like to be able to do this too !
I'm also looking for the answer to this - does anyone have a solution?
Thank you for your posts, and I apologize for the late reply.
Yes, create a script that Hides the Status Bar. That is,
Show/Hide Status Area [ Lock ; Hide ]
This hides the Status Bar and locks it from view.
Once this script is created, pull down the File menu and select "File Options...". Select the "Open/Close" tab, and check the option under Opening this file to Perform script, and specify this new script. Now, when a web user logs in, the Status Area will not be displayed.
Not the answer I was looking for. I figured that one out. I need to know how to stop users of my solution to use the Back and Forward buttons on their browsers but to use just the buttons I provide in my solution. That was my question. Thank you though for trying to help!
I accidentally hit the solved button and haven't found any way to unsolve it. I am looking for disabling the browser's back/forward buttons as well.
Perhaps you should ask yourself this question:
Is there any web site you know where your browser forward and back buttons are disabled while browsing the site?
I suspect that there is no way to do this in IWP and wouldn't be suprised to discover that it's difficult/impossible to do with custom web publishing also.
is there any sort of workaround for the back button breaking in custom web publishing?
The error for me is when i seach from findrecords.php, view the recordlist, then view the browserecord.php page.
At this point the user has decided that this isn't the record they are looking for and they try to hit their browser's back button and are immediately prompted to refresh the page and resubmit form data. This is where everything falls apart.
The problem as I understand it is that as the form uses POST rather than GET for searches, and because it does your search data is stored as an object, rather than in a convenient URL
I have an idea for how to solve this, but it would just be to echo out the object data into a URL format, and then asking the user at the top of browserecord.php "Would you like to return to your search for XXX", but it would be nasty and complicated...
anyone had any success with a workaround?