Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Non-Tech : BrowseMaster for Silicon Investor -- Ignore unavailable to you. Want to Upgrade?

To: jlib who wrote (482)	4/18/1999 11:19:00 AM
From: Craig Richards	Read Replies (3) \| Respond to of 1169

hi Jimmy, Thanks for your thoughts on the auto-refresh feature. I've been thinking about how this should work, as I've realized that the current functionality is less than ideal. Right now I realize that there are problems with auto-refreshing a multiple message screen no matter how it is implemented. No matter what I do, if the user is reading a multiple message screen and it refreshes, the browser will refresh to the start of the page. This is not desired functionality. There are also some other tricky problems with refreshing a multiple message screen in the background while requesting other multiple message screen pages. So this is my proposal for the behavior of the Refresh hyperlink that is displayed on the last message of a multiple message screen for a specific thread: - Selecting the refresh hyperlink will cause an auto-refreshing display of the last message of the current screen. - When that individual message is no longer the last message of the thread, the individual message will be re-directed to a download of that message and any message(s) that follow it. This download will not be auto-refreshing. - When the re-direction to a multiple message screen takes place, BrowseMaster will beep if audio alerts are enabled. - If the user manually refreshes a multiple message download screen of a particular thread, BrowseMaster will now download any new messages on the thread since the original download, while keeping within the configuration parameters for the number of messages per screen. Currently, a refresh of a completed multiple message download screen will not look for new messages on a thread. Let me know what you think of this proposed functionality. Regards, Craig