Feature Request: Change window close to be onClosing

Page: 1 2
ID:132804
 
Oct 10 2009, 8:05 am
I'd like to see the window close command processed before the window is closed. I want the ability to process information on the window using winget before the window closes. Without that feature, we have to remove the "close" buttons and provide our own min/max/close implementation to support "on-closing".

I'm sure this has been asked for before. If anyone has suggestions, I'm all ears.

Changing "close" to be "onClosing" should support both scenarios without regressing behavior. Yes/No anyone?

ts
Oct 10 2009, 9:26 am
Tsfreaks wrote:
...I want the ability to process information on the window using winget before the window closes...

The information on the window isn't effected by it being closed. Whats the problem exactly?
Oct 10 2009, 9:52 am
In response to Falacy
OK. I screwed up. Long story short, I got mixed up about some things and I'll spare you the details.

The problem is actually this. I need to get the ID from the closed window so I need to dynamically set the windows command to "OnWindowClosed 6". 6 is the id of this window.

I've tried to use winset(usr, "MyWindow", "command=\"OnWindowClosed [id]\"");

but the result is a popup dialog requesting input because the verb looks like OnWindowClosed(var/id as text).

Perhaps this is more of a bug or maybe I'm doing something wrong.

ts



Oct 10 2009, 9:59 am
In response to Falacy
For the record, this normally works on other controls. It just doesn't seem to work on the window control.

ts
Oct 10 2009, 10:00 am
In response to Tsfreaks
Add the new command to a macro instead of to a window.
Oct 10 2009, 10:07 am
In response to Falacy
Actually.. I was correct. This thing has me so screwed up. I am unable to add a new command to a window although it works fine for controls. I think this is just a bug or limitation.

I'm not sure how or why I would add it to a macro. I'm not familiar with them yet. I know I can create them for keyboard things. I'll play around with it for a couple minutes and see if I can figure out what you mean.

ts
Oct 10 2009, 10:09 am
In response to Tsfreaks
Oh, right, you wanted that as the close action, not as a macro.
In that case set it as the on-close not the command.
Oct 10 2009, 10:15 am
In response to Falacy
how.... did....I....miss....that.... gaaah! :|

I think that's just what I needed. Ripping through my code now...

Thank you for the smack. Gah.

ts
Oct 10 2009, 10:17 am
In response to Tsfreaks
Tsfreaks wrote:
but the result is a popup dialog requesting input because the verb looks like OnWindowClosed(var/id as text).

Perhaps this is more of a bug or maybe I'm doing something wrong.

Perhaps it's because your verb is set up to expect the argument given to be a text string and you're giving it a number. ;)
Oct 10 2009, 10:20 am
In response to Kaioken
nah... should come across as a string. Works everywhere else except the window command. Of course, I haven't tried var/id as number or whatever the syntax might be.

I don't think it matters though. I'm back into one of my initial problems with this whole thing which I'll explain in another reply.

ts



Oct 10 2009, 10:23 am
In response to Falacy
So... this brings me back to a dead-end of sorts and part of my initial confusion about how window close works. If you close a window that contains a browser control, the browser control is "reset" so 'X' isn't simply "make invisible". That sucks because I have to send/reload all the content when the window is reopened. So, I'm back to needing to override close or provide my own.

Is there a way to override X to be just is-visible=false?

ts



Oct 10 2009, 10:26 am
In response to Tsfreaks
Tsfreaks wrote:
nah... should come across as a string.

With the examples you've shown, as a number, since the resulting command is going to be like OnWindowClosed 6, a command which passes the verb OnWindowClosed the numeric value 6. For it to be a text string, you need to actually designate it as a text string - with quotes. Note the closing quote is optional here, as you don't need to pass any more arguments afterward.

I don't think it matters though.

Well, I assume part of your grand scheme requires that verb to work.
Oct 10 2009, 10:40 am
In response to Kaioken
ok. That's the syntax I was using though right?

Similar to...
"on-close=\"test 18\""


It just doesn't work on the window command at all. I said it was prompting me which is wrong. From what I can tell, you cannot modify the window command at run time.

My current issue is with the browser controls and how they are disposed when the window is closed.

ts





Oct 10 2009, 10:50 am
In response to Tsfreaks
Tsfreaks wrote:
ok. That's the syntax I was using though right?

As mentioned, no.

> "on-close=\"test 18\""
>


Using that in winset() will set the on-close parameter to the value of test 18. You want to set it to the value of test "18", or test "18.

It just doesn't work on the window command at all. I said it was prompting me which is wrong. From what I can tell, you cannot modify the window command at run time.

Just tested it, you can. Ensure that all the arguments are correct.
winset(player,"windowID","on-close='new value goes here'")


My current issue is with the browser controls and how they are disposed when the window is closed.

Something that's worth a shot there is trying to use JavaScript to send (through Topic()) the data you want as the browser control closes using the window.onUnload (you can also try onbeforeUnload) event.
No guarantees it will work, but again, worth a shot.
Oct 10 2009, 11:05 am
In response to Kaioken
Alright, I guess I'm not being clear.

The way I'm doing it for on-close works fine. The 18 makes it all the way to the alert.

winset(player, "windowID", "on-close=\"test 18\"");

...

verb
    test(var/id as text)
        alert(id)


The problem is with the following code. This does not work. windowID in my case would be a cloned window.

winset(player, "windowID", "command=test");

...

verb
    test()
        alert("made it")


hrmm.. maybe if I placed it in the params before window creation. I'll try that if I can.

However, I'm still blocked by the browser controls being reset when the window is closed so all this is pointless aside from learning.

Appreciate the suggestions all the same.
ts
Oct 10 2009, 12:03 pm
In response to Tsfreaks
Tsfreaks wrote:
The way I'm doing it for on-close works fine. The 18 makes it all the way to the alert.

I see it's actually lenient enough to accept numbers as text. Nevermind, then.

The problem is with the following code. This does not work. windowID in my case would be a cloned window.

> winset(player, "windowID", "command=test")


Huh? Since when do windows even have a command parameter? I missed you mentioning this one before.

However, I'm still blocked by the browser controls being reset when the window is closed so all this is pointless aside from learning.

So, you didn't try my JS suggestion?
Oct 10 2009, 12:07 pm
In response to Kaioken
No, I didn't miss your js idea. Getting the close event is now easy enough with the on-close property. The part I need to figure out is why the content in the browser object gets disposed after closing the form. 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. I need close to act like is-visible=false instead.

ts
Oct 10 2009, 12:47 pm (Edited on Oct 10 2009, 12:52 pm)
Tsfreaks wrote:
I'd like to see the window close command processed before the window is closed. I want the ability to process information on the window using winget before the window closes. Without that feature, we have to remove the "close" buttons and provide our own min/max/close implementation to support "on-closing".

I'm sure this has been asked for before. If anyone has suggestions, I'm all ears.

Changing "close" to be "onClosing" should support both scenarios without regressing behavior. Yes/No anyone?

I'm fairly certain that by the time the containing window calls on-close, the contents of the browser control are wiped out (which is what I think you're running into). Why not try using the onunload tag on the body element? This runs the inconvenience of having to manually send along everything you need as GET params, but it should work. If you're using a form designed for use in a BYOND topic (action set to "byond://") you could also just call its submit() function in the same fashion instead.
Oct 10 2009, 12:57 pm
In response to Mobius Evalon
Thanks for repeating what I suggested; hopefully he got it this time.
Oct 10 2009, 1:01 pm
In response to Tsfreaks
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.

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. 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.

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.

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

Hmm, so it doesn't?
Page: 1 2