Why am I loosing llDetectedKey facility?

Obviously this is part of a much bigger script.

I had this section working - changed something and now when I move to the State OwnerMenu I loose the ability to llDetectedKey ??

It is something to do with jumping to state OwnerMenu

//Menus
string message = "";
key id = "";
integer CHANNEL = 41;// dialog channel
list MENU_OWNER = ["use for self","Test"];
list MENU_STAFF = ["Replce Note", "Replce_PIC", "Off"];

default
{
touch_start(integer num)
{
llSay(0, llDetectedKey(0));//test
state OwnerMenu;
}
}


state OwnerMenu
{
state_entry()
{
llListen(41, "", NULL_KEY, ""; // listen for dialog
llDialog(llDetectedKey(0), "What do you want to do?", MENU_OWNER, CHANNEL); // present dialog on click
llSay(0, llDetectedKey(0));//test
}
listen(integer channel, string name, key id, string message)
{
if (llListFindList(MENU_OWNER, [message]) != -1) // verify dialog
{
llSay(0, name + "pick " +(message) + "'.";
if (message == "use for self"// Action
{
llSay(0, "Use for Self";
}
else if (message == "Test"// Action
{
llSay(0, "Test";
}

}
}
}

you cant detect jack in state entry

It wasn't Jack I was looking for - but thanks it answers the question

I'm sure it is helpful but it doesn't mean 'Jack' to me - can anyone give me an example please

As the wiki info he quoted states, the llDetected* functions only return valid results in specific events and state_entry is not one of them. Store the value in a global variable before you switch states and access it that way.

OK - thanks people - I now have the menus up but they display but the script and move on before you have chance to click the selection.

That didnt mean Jack to me....
can you elaborate? i.e. post the new code and explain the problem a bit better?

Jack is getting a real working out here - I found the problem - I didn't have the listen in the correct place - the script is now working and it has been told all is forgiven.

Thanks everyone for your patience.

Tarak

Just on a side note, if you are going to add a listener each time you enter the menu state, you should probably call llListenRemove (or whatever its called) after you process the listen event. AFAIK listeners can be stacked, so over time you may queue up several listeners and possibly cause an issue.

Of course that really depends on how exactly the listeners work, it may not be an issue, can't hurt though to remove the listener when you are done with it (or add it once and not re-add on temporary state entries.)

once you switch states they are gone

course this does NOT mean that a glitch will happen in 6 months where listens die on state change but still get stuck in ram so it might be a good idea anyways