client
verb
focus(tab as text|null)
if(!tab) return
if(current_chan) winset(src, "[current_chan].chat.input1", "is-default=false;")
current_chan = tab
winset(src, "[tab].chat.input1", "is-default=true;")
Problem description:
I winclone panes that contain an input and an output element to act as channel windows in a tab element. Each channel is its own tab, with its own input and output. When focus is given to a tab, the input for that tab must become the default. This verb is called by the interface when a tab gains focus. Most of the time, this works fine. However, after using winset to remove the tab by setting the pane's parent to null, the tab that then remains does not get its input set to default. The interface does not automatically call the focus verb, so I call it manually in the quit command that closes the tab and removes the cloned pane.
Strangely, if I add an alert() after the is-default=true winset call in focus, it DOES get set to default, as expected. This makes me think BYOND is getting stuck, or confused, or ... something.
I noticed that if an input element is set to default, any attempts to set another fails. I have to manually set the current default input to is-default=false before I can set another input to default. I do this, but this bug is acting like I am not.
Actually, that's not correct. When an input is already set to default, or no input element is set to default at all, and I try to type, nothing appears to happen. When this bug happens and I try to type, I get a chime sound. It's like it's trying to send input to an element that no longer exists, so an error chime occurs. That's not right. I've already set the removed input element to is-default=false. I tested the code, and it does execute. Or does it? I get output from that code block, but who knows what happens in the interface when you use winset.
The alert oddness is very strange. Seems like a BYOND bug, but it's been a while since I practiced interface-fu.
