In response to Kaioken
Kaioken wrote:
Thanks for repeating what I suggested; hopefully he got it this time.

Oh, awesome. I think right around that post is where I figured nobody suggested it yet given the number of replies, and just scrolled back up to the parent to post.
In response to Kaioken
Kaioken wrote:
Tsfreaks wrote:
No, I didn't miss your js idea. Getting the close event is now easy enough with the on-close property.

You didn't miss it, but you didn't understand its point.
... still don't. I'll give it another read.
The part I need to figure out is why the content in the browser object gets disposed after closing the form.

I don't think the question to ask here is "why". That's just how it is.

The question is most certainly "why". Why do we reset the browser windows? Is there a real reason or was it simply not addressed as part of the initial design. The answer to "why" will tell me if changing it is possible.

Presumably, when the window is closed (hidden), the embedded IE browser in it is entirely closed. When the window is shown again, a new embedded browser is opened in >it.

Well, then we need to understand what the difference between "close" and "is-visible=false". They are not the same. Closed should mean closed, exited, finished, gone, bye bye. The design where the windows are all created but hidden is sort of weird. I could care less though. Whatever... as long as we don't blow away the browser content when we hide the window via close.

I have a ton of DB stuff in the web page and when the player wants to redisplay the window, I don't want to requery and send the data all over again.

Why would you need to requery it anyway? Considering you just had the data since you recently fed it into browse(), an available and suitable option is to temporarily cache that data for a certain amount of time in case it's needed again, to prevent requerying.
My understanding of how that works is a bit fuzzy. If I were to store the "result" string in a mob/var/list, would that be stored locally on the client and when I send that information to a browser control, would that be a client side only operation?

I need close to act like is-visible=false instead.

Hmm, so it doesn't?
No. Browser windows reset with close and don't with is-visible=false. I refer to that as "different" where I come from. :|
In response to Mobius Evalon
Thanks for the suggestions.

When the window closes, I wanted to prompt the user to see if they wanted to save the changes before closing. Giving them the option to cancel as well.

A cancel choice would leave the window open. A save choice would collect the data from the browsers, save the changes, and then close the window.

That's the main reason for wanting to override the behavior of close. The second part was that I don't want the browsers blown away on close.

ts

mob/verb/MyData()
usr << browse("BlahBlah","file=Myawsomedata.html")
mob/verb/SimulateMyDataDieing()
usr << browse("")
mob/verb/BringItBack()
usr << browse("<iframe src=Myawsomedata.html>")

Would something like this make you feel better?
Page: 1 2