ID:1836686
 
(See the best response by Turboskill.)
obj
Fetus
Click()
if(Mkey == usr.ckey)
alert(usr, "You are about to set the options for your baby. Put a password if you want to lock the login for this baby with a password. Put a name if you want to name your baby. When you're \
finished just press \"Allow Login\" so that it'll show up in the login screen. Finally press save and close to save all the options."
)
winshow(usr, "Fetus Options", 1)
winset(usr,"Fetus Options","pos=500x500")
winset(usr, "Fetus Options.Name", "text='[bname]'")
winset(usr, "Fetus Options.Password", "text='[password]'")

verb
Close()
set hidden = 1
password = winget(usr, "Fetus Options.Password", "text")
bname = winget(usr, "Fetus Options.Name", "text")
if(bname == "")
name = "Fetus"
bname = null
else
name = "[bname]"

var/radios = params2list(winget(usr, "Login", "is-checked"))
if(radios["Login.is-checked"] == "true")
open = 1
else
open = 0

winshow(usr, "Fetus Options", 0)



Basically I've it set up so people can edit a fetus in their inventory by clicking on it. The first part is all fine, however when it comes to closing it there is a problem. I just use "Close" as the command to close the window(when it asks for a command for buttons or what to call when a window is closed in interface), which doesn't actually work. I would have to call "Close Fetus" for it to actually work. However, if the fetus is called anything else then it'll need to call "Close [Fetusname]". Another issue is, is if the player has more than two fetus' in their inventory. If they click the second one to edit it, and it closes using "close fetus" who knows which one it will actually edit. What is a proper way to go about handling this? Using a for loop and making the close verb derive from the mob?
Best response
Well what i'd imagine is that you're only trying to call this particular Close() verb from only one button that belongs only to the fetus window right?

In that case, ignoring the fact that the way you have this is providing something quite different from what you intend, what you could do instead is rename and reposition the verb, having it as a mob (and thus window) accessible verb e.g.
mob/verb/CloseFetusWindow()
set hidden = 1

//you could have checks like is this a usr? and so on but it's mostly unnecessary.

if(winget(usr,"Fetus Options","is-visible")=="true")// in case of being activated from the
// command line or prompt box
[relevant code here]


And then in your interface file, on the relevant button type CloseFetusWindow in the command field to indicate you want to call that verb when the button you're using for close is clicked.

So thats about it, just that with stuff like accessing the obj vars you would then need to be like
usr.Fetus.password = ...
usr.Fetus.bname = ...
And so on (maybe just even using src.Fetus.bname i.e. Fetus.bname would be fine in this situation, but thats something you might want to decide yourself, i haven't thought too much about it for this scenario).

Alright, so the reason i suggested that no checks of the type 'is this a mob with a key as opposed to an npc?' are necessary is because.. well non-player mobs shouldn't be able to run this command at any point regardless, whether to click a fetus in order to open a window in the first place or click/enter the command to close it. Pretty straightforward :P.

Edit: erased last paragraph, tested it and checking is-visible works correctly with both winset and winshow.
Edit 2: Added some details that i'd forgotten.
The reason I added the check is because admins can look into the inventories of others and click stuff in their inventories. I didn't want them to be able to edit the fetus' of other players unless they used the edit verb, where it would be logged. Thanks for the help, fixed my code!
Ah. I was wondering what it was you were talking about, but i see you did indeed have a key check in the click portion of the code. Yeah no worries about that, makes sense. Actually i didn't realise it was there (only really scanned the click proc at the time), so when i made the comment about checking for usr, that was just in general and not to do with that code in particular.

By the way i made an edit to my first post to address the other part of the process to do with the interface that you'd need to get this working. i'd meant to put them in earlier and forgotten. It already looks like you've got the system working, but just in case.