Works for me...not for them.

I have a linked prims whereby you click on one prim and it brings up a dialog box with colour choices. You select the colour and the other prim changes colour via a link message command. All this works great for me, but when i gave a mod, no copy, trans copy of the item to a friend the colour dialog menu would work, but the colour wouldn't change.

Am I missing something?

Most commonly the dialog listener is still listening to you.

Try adding this code to the script:

    on_rez(integer start_param)
    {
        llResetScript();
    }

-peekay

Thanks for your help that's exactly what the problem was. You learn something new everyday

Sounds like you are using an open listen in state_entry. BAD practise for soemthing that is tocuh activated.
Since you state they have to touch it to get the dialog have the listener be recreated at that point.

Not sure what is meant by an "open listen". The following code is the genral layout I'm using.

state_entry()
{

llListenRemove(mnuHandle);
dialog_channel = llRound(llFrand(900000) + 100000) * -1;
mnuHandle = llListen( dialog_channel, "", llGetOwner(), "";
}

touch_start(integer total_number)
{
llDialog(llGetOwner(), "Choose colour", MENU_OPTIONS, dialog_channel); }

listen(integer channel, string name, key id, string message)
{
if (llListFindList(MENU_OPTIONS, [message]) != -1)
{
if (message == "Red"
{
llSetColor(<1.0,0.0,0.0>, ALL_SIDES);
llMessageLinked(LINK_SET, 0, "<1.0,0.0,0.0>", NULL_KEY);
}

else if (message == "Blue"
{
llSetColor(<0.0,0.0,1.0>, ALL_SIDES);
llMessageLinked(LINK_SET, 0, "<0.0,0.0,1.0>", NULL_KEY);
}

else
llSay(0, name + " picked invalid option '" + llToLower(message) + "'."; // not a valid dialog choice
}
}
}

Is there anything there that is horribly wrong?

You need to consider that state_entry only ever executes when a script first runs, or when it's reset.

Therefore these lines of code...

lListenRemove(mnuHandle);
dialog_channel = llRound(llFrand(900000) + 100000) * -1;
mnuHandle = llListen( dialog_channel, "", llGetOwner(), "");

...do not get executed when the object passes to a new owner.

Hence llResetScript is one solution.

Another solution is to put those lines into a function...

initListen()
{
    lListenRemove(mnuHandle);
    dialog_channel = llRound(llFrand(900000) + 100000) * -1;
    mnuHandle = llListen( dialog_channel, "", llGetOwner(), "");
}

...then call ths function from state_entry...

state_entry()
{
    initListen();
}

...and finally - and this is the good bit - call it when the owner changes...

changed(integer change)
{
    if(change & CHANGED_OWNER)
    {
        initListen();
    }
}

This has some advantages. The same code is reused whenever you want to set the listen. The script doesn't need to be reset - you will eventually find that resetting scripts is not always convenient. Complex scripts often exploit their persistent nature so it's a good idea to get the hang of understanding how to actually avoid, in effect, powering off and on your scripts to have them work properly.

I consider any listen that is set up with out a timeout to be an open listen.
Since your device is touch activated it only needs to listen when its been touched, so you are wasting resources by listening at other times.

Colour look ups have been posted previously try this thread

I only started writing scripts a month ago with no prior knowledge of programming and I do get a sense of satisfaction when something works or even when SL says "compiled successfully" without a series of Error commands.

It's suprising just when you think you have your code down correctly you find out new more efficient ways of doing things. Regarding the InitListen function method, my script is very simple and short and only needs to be called once so I won't go that route this time. But it certainly makes for a more readable script. The "changed" piece of code is a definite winner for me and I am going to implement that for sure.

I have being looking at the timer function on the Wiki. Would this in effect close the dialog menu after a certain period of time? I am unsure where to work this kind of function into my script.

All my work in trying to create my script and I never once came across these funcitons. I am starting from square one

Thanks for the help guys much appreciated.

We all start that way, I still find new things as I look at scripts, either my own or someone elses!

The timer shuts down the listen, you cannot unfortunately close the dialog box automatically. It is good practise to make your listens only work when required.

The chanegd event is very useful, it allows tyou to react to updates without having to manually reset the script, Especially when working with notecards or inventory.

Following your previous colour changing script in the other thread there are these lines of code:

on_rez(integer number) { llResetScript();}

changed(integer change) { if (change & CHANGED_OWNER) llResetScript();}

Does this reset the script first regardless of owner change and then check for ownership change?

No.

The script resets when ever it is rezzed and will also reset if the owner has changed.

To implement a time-out your listen set up would need to include an additional line for llSetTimerEvent...

llListenRemove(mnuHandle);
dialog_channel = llRound(llFrand(900000) + 100000) * -1;
mnuHandle = llListen( dialog_channel, "", llGetOwner(), "");
llSetTimerEvent(120); //<---

...and then the timer event itself would look like this...

    timer()
    {
        llSetTimerEvent(0);
        llListenRemove(mnuHandle);
    }

However you'll then no longer be able to rely on the state_entry, or change events to issue the llListen, because it's going to time out after two minutes. Soo... something like this will need to be in touch_start...

llListenRemove(mnuHandle);
dialog_channel = llRound(llFrand(900000) + 100000) * -1;
mnuHandle = llListen( dialog_channel, "", llGetOwner(), "");
lDialog(llGetOwner(), "Choose colour", MENU_OPTIONS, dialog_channel);
llSetTimerEvent(120);

I, of course, would drop all this code into a function and call that from the touch_start.

For what it's worth, in a product I sell. I offer a user configured time-out value (which can be to never time-out). There's no perfect answer of how to handle a listen time-out, or how to handle the llDialog ignore button. Anything that requires user input often carries a certain ambiguity.