I want to detect and close a browser window. But before closing the browser page I need to update a SQL entry in an InUse table. There are a couple of unique situations added to this. When the EditPage.aspx opens for a (recordID record in a MstrTbl) I place an entry in the InUse table. I am tracking recno (autogenerated), userid, sessionid, recordID (MstrTbl), status, rectype, rwindicator, createdatetime, updatedatetime. I am using Session("gUserID") [all Session("variables")] when updating InUse table. The variables are fairly straight forward. But, there can be multiple users opening the same recordID, however, only 1st user in can edit. (Thus, rwindicator, Read/Write Indicator). In days of yore, you could control a vb6 app opening only once, but now in web world, a user can open multiple browsers (and records), and in this case need to be able to do so.
Okay, so if there is an InUse entry for this user, and this recordID, redirect the 2nd attempt to an error page (You can only open this record once) error, and back to the Default page for you.
Now a user is finished with a record, and can click Home (Site.Master Menu Item) or can simply click "X" in browser. I DO NOT want a "verify close" message (extra click), but where the InUse table had an [A]ctive status now needs updating time stamp and e[X]pired status. The solution can be java or jquery. I have tried several renditions of many attempts at "catching" the close with window. Using a hidden "btnCloseWindow" in a onbeforeunload functions seems to almost work a larger percent of the time, especially if I set an "alert" msg (which I do not want to do).
Code in the Window.close seems to never be able to update the InUse record. I've also tried timeout intervals. I have tried a dozen variations of different "solutions" (from other programmers attempts) but none seem reliable, if I get 2 or 3 users opening 3 or 4 of the same records, then closing them one at a time. I can create the InUse record. That's easy enough. But when a user closes a recordID, it will not update date/time stamp and status from [A]ctive to e[X]pire. I do not want to insert and delete records. This is an audit trail. But if the same userID opens the same recordID and it still shows [A]ctive, it will not allow the user to (in error) open it again.
The code in the EditPage.aspx.vb runs a Public Shared Sub (RecData.LockRec) in code behind, but then needs to run (RecData.CloseRec) when the "X" or "Home" Menu item is clicked.
In advance, any help is appreciated.
You can use window.onclose event but note you have a very small amount of time so your backend has to accept the posted event quickly. The browser will only wait for a short amount of time. So if you are doing anything complicated, accept the POST/GET from the client and then close the connection and then process the POST/GET.
Related
I am wondering how to make a JavaScript popup message (display for 5 seconds) when a database input for specific users have changed? Kind of like the Xbox live achievement message that comes up each time you do a specific task, but i want mine to check if the level for a specific user changes and then have a popup message saying "Congratulations on reaching level x". I'm going to have a popup message for other things than just level as well so it would need to be easy to design.
I couldn't find anything online so if any of you have any suggestions, please leave me some links.
either use a timer and ask via ajax in an interval for new popups
or use websockets/websocketserver to push that info to the client
When a user clicks a link in his inbox, I want to mark the message related to the link as seen.
SO has this feature as well,
If someone replies to my post, SO shows something happend to my post.
After I click the inbox message and visit the post, SO no longer shows notification mark.
I guess it's too expensive to test if visiting user of a question has an inbox message every time a user visits any question page.
I wonder if it's possible to catch clicking-link in the inbox page, so that I can send ajax request under the hood to mark the message as seen
Hope my questions are clear.
Add a custom data attribute to each message you click. I'm not sure how your displaying messages, but for this example we'll use a span:
<span class="message">Some Message</span>
And the JS:
$(".message").click(function() {
$(this).data("visited", true);
});
Then you can check spans to see if they've been visited. If you still want to do the AJAX call, you can simply add an AJAX event inside the click handler as well.
I'm assuming you have some sort of 'status' field on your messages table to differentiate between 'Read' and 'Unread'.
If you are asking how to efficiently store the number of unread messages in an inbox without running a query on every page load, this can easily be accomplished by setting a $_SESSION variable:
$_SESSION['unread_messages'] = 2;
After this variable is set, you can periodically check (every 5 minutes or so) to keep this up to date within a reasonable window. When a message is clicked and read, you will subtract 1 from this value or re-query the number of unread messages.
If you are asking about how to update the database and UI, there are 2 main ways you would go about doing this. It will depend on what currently happens in your script when a user clicks on a message. Do you make an AJAX request to load the message, or does the link take the user to a different page?
If you make an AJAX request when a message is clicked, simply have the script that is called in the AJAX request also mark the message as read (in the database), and use JavaScript to make any UI updates to the current page (such as removing bold text on the message that was clicked).
If clicking on a message redirects to a different page where the entire message is displayed, you can mark the message as read in the database when that page loads.
I have a bit of an issue with page formatting when I navigate away, and then hit browser back to a page.
Here is an example:
I have security questions on a form in a drop down list like so:
http://i.stack.imgur.com/ib32z.jpg
When the user selects [Type in your own question] from the drop down list, I have some jquery that animates a CSS change that pushes the form down, and makes visible a hidden field for 'custom security question'. When selected, the form looks like this:
http://i.stack.imgur.com/uVPKo.jpg
Now my dilemma is when I navigate away from this page, and then navigate back using the browsers back button, my formatting gets screwed up and looks like this:
http://i.stack.imgur.com/5Xhpi.jpg
The javascript that I have written does not trigger again on the back button so the browser doesn't know to move the form back down to accomodate the change in spacing. Is there anyway I can force the document.ready to reload or clear some kind of cache?
Thanks!
EDIT: Sorry guys, I need to reupload the images to a host and repost. Sorry for the delay.
There are basically four mechanisms for persisting state on the web:
Browser-based - the browser, if you're lucky, will save answers to form fields and re-display them when it sees an INPUT with the same name; also, some browsers will preserve some state between forward<=>back navigation
Cookie-based - pretty self-explanatory; you save a cookie with the state info, and check it later to recover the state
URL-based - navigate to a different hash of your URL, with the info you want in it (eg. "?roll_down=true")
HTML5/Local Storage - Look it up if you're interested :-)
We can basically throw 1 and 4 out, because they both rely too much on browser behavior/support, and we can't reliably rely on all browsers to handle them the way we want. That leaves #2 or #3.
Cookies allow you to save more info (as much as a cookie holds, ie. about 4k). URLs allow less info, but they have the added benefit of bookmark-ability; if the user saves the URL as a bookmark (or as a link they send a friend, or whatever), the state still gets preserved.
So, take your pick of the above, decide on how to persist your "my form is rolled down" state ... and then comes the part that (I think) you're really interested in: how do you check this state and fix things when the user clicks "back"?
That part I humbly defer to another SO post, which has already answered it:
Is there a way to catch the back button event in javascript?
I have a web site that displays a table of contents, and I'd like to use the Google Plus One button as a kind of persistent "favourite" marker. So a user would Plus One a page, and then in my table of contents I would show that page as being "Plus Oned" somehow (either bold the entry, show a plus image or something similar).
So is there any way to call the Plus One api to find out if a URL has been "Plus Oned" by the current user?
Note that I don't want to get the plus one count (as shown at http://www.tomanthony.co.uk/blog/google_plus_one_button_seo_count_api/) and I don't want to have to manually intercept plus one clicks and store the details myself.
http://www.tomanthony.co.uk/blog/google_plus_one_button_seo_count_api/ may do what I want. The isSetByViewer parameter that is returned is possibly what I want, but simply calling the web service as described in the web page always returns a isSetByViewer value of false. I would assume that some other undocumented data or cookie/header information would have to be sent to the web service identify the current user.
There is a pos.plusones.getSignupState in the hidden API, which you can try to experiment with instead of pos.plusones.get. Other than that, I think you should specify the G+ user id in the userID parameter.
Furthermore, you can try to sniff the network traffic for the +1 button with wireshark, webkit inspector and chrome://net-internals (watch SPDY traffic to client6.google.com). OR you could try to debug the js code with step to find what variable makes the +1 button highlight.
I'm having hard time trying to figure out how to auto-save user data in a form when the browser is being closed or user changes the page. The onBeforeUnload event is OK when you want to open a dialog box, but by then it's too late to save the changes (except if you just block the browser in the onBeforeUnload handler long enough for it to pass the request to the server...but I'd rather not do that).
I am sure some of you have had to deal with the unsaved form problem. What do you do? Do you:
let users just lose their changes,
ask them using a modal window if they are sure they did the right thing,
save individual fields on the fly as they change,
or do you have some ultimate method to automagically save the data when it's about to be lost irretrievably?
•ask them using a modal window if they are sure they do the right thing,
Closing a window is an act of cancellation. As the user never actively submitted the form, theres no guarantee that they want the data saved (it may not be correct), and you saving the data could cause problems for the user.
I like your third option:
save individual fields on the fly as they change.
I'm having to deal with a similar situation, and that's what we are doing. The two main things that sell that to me:
Improved user experience - the user
will be impressed by a form that
does not lose changes. They are
'committed' once they are validated.
E.g., he types in a valid email
address, and it is saved instantly,
furthermore he is provided some sort
of feedback for each field that is
successfully been saved (a green
tick for example, appears next to
the field).
No more 'oh crap my browser crashed
and I lost all my info' situations.
Disadvantages: The extra man-hours involved in developing such a solution, and the possibly that it ends up not degrading as nicely as a simpler solution. That said, it is still worth it IMO.
In any browser I have used it in, onBeforeUnload provides you with a modal window which asks the user to confirm whether they want to leave the page or not. You can added your own text warning them that there is unsaved data, to help them decide. You don't want to explicitly save without the user's request, because a) the user did not attempt to save, and b) if you need to throw any validation errors it will be too late as the page is already in the process of navigating away.