[Emmet_]

easyDialog.inc

Introduction
I've released this include a little over a year ago. However, it didn't have many features and it wasn't crash proof, so I've decided to scrap it and rewrite the whole include from scratch.

Purpose
The purpose of this include is to make dialogs easier to use in general.

Imagine having over 100 dialog checks under OnDialogResponse. It's just too messy and most of the time, it's unorganized and harder to look for certain dialogs for future editing, and remembering certain dialog ID's can be a pain in the ass.

However, easyDialog.inc fixes that by introducing a "named dialog feature" which allows scripters to declare a dialog by name, rather than ID.

Feature	OnDialogResponse	easyDialog.inc
Crash Proof	No	Yes
Named Dialogs	No	Yes
Calling a dialog manually	No	Yes
Custom callback for handling	No	Yes

This code:

pawn Code:

#define DIALOG_WEAPON (1337)

CMD:weapons(playerid, params[])
{
    ShowPlayerDialog(playerid, DIALOG_WEAPON, DIALOG_STYLE_LIST, "Weapon Menu", "9mm\nSilenced 9mm\nDesert Eagle\nShotgun\nSawn-off Shotgun\nCombat Shotgun", "Select", "Cancel");
    return 1;
}

public OnDialogResponse(playerid, dialogid, response, listitem, inputtext[])
{
    if (dialogid == DIALOG_WEAPON)
    {
        if (response)
        {
            new str[64];
            format(str, 64, "You have selected the '%s'.", inputtext);

            GivePlayerWeapon(playerid, listitem + 22, 500);
            SendClientMessage(playerid, -1, str);
        }
    }
    return 1;
}

Turns into this code:

pawn Code:

CMD:weapons(playerid, params[])
{
    Dialog_Show(playerid, WeaponMenu, DIALOG_STYLE_LIST, "Weapon Menu", "9mm\nSilenced 9mm\nDesert Eagle\nShotgun\nSawn-off Shotgun\nCombat Shotgun", "Select", "Cancel");
    return 1;
}

Dialog:WeaponMenu(playerid, response, listitem, inputtext[])
{
    if (response)
    {
        new str[64];
        format(str, 64, "You have selected the '%s'.", inputtext);

        GivePlayerWeapon(playerid, listitem + 22, 500);
        SendClientMessage(playerid, -1, str);
    }
    return 1;
}

I think the second example is much more neater, especially for larger scripts.

Callback
This script introduces a new callback:

pawn Code:

public OnDialogPerformed(playerid, dialog[], response, success)
{
    return 1;
}

This callback is called before a dialog is shown to a player (using Dialog_Show, that is). Returning 0 under this callback will prevent the dialog from working.

pawn Code:

public OnDialogPerformed(playerid, dialog[], response, success)
{
    if (!strcmp(dialog, "WeaponMenu") && IsPlayerInAnyVehicle(playerid))
    {
        SendClientMessage(playerid, -1, "You must be on-foot to spawn a weapon.");
        return 0;
    }
    return 1;
}

Very simple, isn't it?

Functions
This include introduces several new useful functions:

pawn Code:

Dialog_Show(playerid, dialog, style, caption[], info[], button1[], button2[]);

Shows a dialog to a player.

pawn Code:

Dialog_Close(playerid);

Closes any opened dialogs.

pawn Code:

Dialog_Opened(playerid);

Returns 1 if the dialog is opened for the specified player.

Download
easyDialog.inc (Pastebin)
easyDialog.inc (Solidfiles)

Example Script (Pastebin)
Example Script (Solidfiles)

This include doesn't work...

a) Update to the newest version
easyDialog was originally released in 2012, and the latest stable version was released on March 31, 2015. You must update to the latest version for the latest features and bug fixes.

pawn Code:

// easyDialog v1.0 Syntax:
ShowDialog(playerid, Show:MyDialog, DIALOG_STYLE_LIST, "List", "Items", "Select", "Cancel");

// easyDialog v2.0 Syntax:
Dialog_Show(playerid, MyDialog, DIALOG_STYLE_LIST, "List", "Items", "Select", "Cancel");

easyDialog works in parallel with OnDialogResponse, so you can use both at the same time. Older versions do not support this.

b) Includes and filterscripts
Returning 0 under OnDialogResponse will pass the dialog to other scripts containing the callback. However, certain filterscripts and third-party libraries might return 1 instead. This interferes with the inner workings of easyDialog and causes the dialogs to not work.

Simply return 0 instead to fix the issue.

[iZN]

Decent work Emmet_. It is good for the scripters who easily gets confused with the dialogs.

[Konstantinos]

I used the old include and it was really useful. Of course, I'm going to use the new version of it! Everything is great and the new callback, then only thing I don't get is how/where to use Dialog_Call function. Would you mind to give an example?

Thanks and great job!

[xSiiLenTx]

Sent this to my scripter for my server, thank you very much +rep

[Emmet_]

Thanks guys!

Quote:

Originally Posted by Konstantinos I used the old include and it was really useful. Of course, I'm going to use the new version of it! Everything is great and the new callback, then only thing I don't get is how/where to use Dialog_Call function. Would you mind to give an example? Thanks and great job!

Thanks for the feedback!

It's for explicitly calling a dialog. For example, if I had this dialog in my script:

pawn Code:

Dialog:MyDialog(playerid, response, listitem, inputtext[])
{
    if (response)
    {
        // Some code here.
    }
}

And I wanted to execute the code after if (response) then I would do this:

pawn Code:

Dialog_Call("MyDialog", playerid, 1, 0, "\1");

However, the last parameter must be "\1" or " " instead of "" due to a glitch with the "CallLocalFunction" function. The explanation might be a bit difficult at first; sorry about that.

[Konstantinos]

It's alright, I understood it. Thanks for the explanation.

[Pottus]

I think this look pretty good one thing I think could have been done differently is this.

Doing this looks ugly to me and doesn't really make sense given the way dialogs are organized with your include in this manner.

pawn Code:

public OnDialogReceived(playerid, dialog[], success)
{
    if (!strcmp(dialog, "WeaponMenu") && IsPlayerInAnyVehicle(playerid))
    {
        SendClientMessage(playerid, -1, "You must be on-foot to spawn a weapon.");
        return 0;
    }
    return 1;
}

This makes a lot more sense to me

pawn Code:

DialogRecieved:WeaponMenu(playerid, success)

[Emmet_]

Quote:

Originally Posted by [uL]Pottus I think this look pretty good one thing I think could have been done differently is this. Doing this looks ugly to me and doesn't really make sense given the way dialogs are organized with your include in this manner. pawn Code: public OnDialogReceived(playerid, dialog[], success) {     if (!strcmp(dialog, "WeaponMenu") && IsPlayerInAnyVehicle(playerid))     {         SendClientMessage(playerid, -1, "You must be on-foot to spawn a weapon.");         return 0;     }     return 1; } This makes a lot more sense to me pawn Code: DialogRecieved:WeaponMenu(playerid, success)

That's a better concept than mine, thanks!

I was thinking that "WeaponMenu" for example could be a real constant ID rather than a disguised string, so then I can do something like:

pawn Code:

public OnDialogReceived(playerid, dialog, response)
{
    if (dialog == WeaponMenu)
    {
        // code
    }
    return 1;
}

[Pottus]

I think it's best to keep consistent with the established style it makes it easier to group code because who knows where OnDialogReceived() is going to be in location.

[Swedky]

Nice!

[StuartD]

This is a nice re-release Emmet_, It is well explained as well. I may use this.

[mike358015]

Because this calls the functions directly, not browsing all the if-else or switch statements one by one, can this be faster than normal method?

Anw, have been using your older version of this, and I have to say, it's pretty much better and easier to manage than the normal way. Thanks for the nice includes, Emmet_.

[Pottus]

Quote:

Originally Posted by mike358015 Because this calls the functions directly, not browsing all the if-else or switch statements one by one, can this be faster than normal method?

The speed is too small to be effectively measurable so it is really irrelevant what is relevant is the ability to organize dialogs in their own functions which is beneficial design wise. I would use y_inline/y_dialogs myself but this method lives up to production quality standards and is good for both beginner and intermediate scripters alike.

[Emmet_]

Quote:

Originally Posted by mike358015 Because this calls the functions directly, not browsing all the if-else or switch statements one by one, can this be faster than normal method? Anw, have been using your older version of this, and I have to say, it's pretty much better and easier to manage than the normal way. Thanks for the nice includes, Emmet_.

I've yet to perform some tests, but I suppose that this include could be faster, especially with scripts that use many dialogs.

For example, having a lot of checks under one callback (in this case, OnDialogResponse) clutters the script and makes it look unorganized for most people, and that's more work for the script to process during runtime. It's similar in a way with scripts having many strcmp checks under one callback (OnPlayerCommandText), which is frowned upon by most scripters today.

I wanted to craft a script that had a similar layout to zcmd, not only for better organization, but to provide a more reliable and easier way for scripters to handle dialogs, rather than having them throwing code under one callback. Thanks for the feedback!

Quote:

Originally Posted by [uL]Pottus The speed is too small to be effectively measurable so it is really irrelevant what is relevant is the ability to organize dialogs in their own functions which is beneficial design wise. I would use y_inline/y_dialogs myself but this method lives up to production quality standards and is good for both beginner and intermediate scripters alike.

I've never heard of y_dialogs before, I should probably check it out.

[Pottus]

Quote:

Originally Posted by Emmet_ I've yet to perform some tests, but I suppose that this include could be faster, especially with scripts that use many dialogs. For example, having a lot of checks under one callback (in this case, OnDialogResponse) clutters the script and makes it look unorganized for most people, and that's more work for the script to process during runtime. It's similar in a way with scripts having many strcmp checks under one callback (OnPlayerCommandText), which is frowned upon by most scripters today. I wanted to craft a script that had a similar layout to zcmd, not only for better organization, but to provide a more reliable and easier way for scripters to handle dialogs, rather than having them throwing code under one callback. Thanks for the feedback! I've never heard of y_dialogs before, I should probably check it out.

Basically it allows you to embed all your dialog code within a function.

Look here https://sampforum.blast.hk/showthread.php?tid=295049

[Twizted]

Oh Emmet_, you never let anyone down, do you?

[PT]

nice include man

very useful

[newbie scripter]

just a question. Do we need to define the dialogid liek
#define BLAH 111 ??

[Emmet_]

Quote:

Originally Posted by newbie scripter just a question. Do we need to define the dialogid liek #define BLAH 111 ??

Nope, just this:

pawn Код:

Dialog:MyDialog(playerid, response, listitem, inputtext[])
{
    ...
}

Dialog_Show(playerid, MyDialog, style, caption, info, button1, button2);

[Yves]

thanks man