SelectTextDraw and ShowPlayerDialog - cancelling with ESC logic problem

SelectTextDraw and ShowPlayerDialog - cancelling with ESC logic problem - Printable Version

+- SA-MP Forums Archive (https://sampforum.blast.hk)
+-- Forum: SA-MP (https://sampforum.blast.hk/forumdisplay.php?fid=3)
+--- Forum: Bug Reports (https://sampforum.blast.hk/forumdisplay.php?fid=20)
+--- Thread: SelectTextDraw and ShowPlayerDialog - cancelling with ESC logic problem (/showthread.php?tid=644546)

SelectTextDraw and ShowPlayerDialog - cancelling with ESC logic problem - IstuntmanI - 10.11.2017

Not necessary a bug, but it is a problem with the logic:

Using SelectTextDraw and then ShowPlayerDialog (well, the order doesn't matter, same effect) has a problem: if pressing ESC (cancelling) then the OnPlayerClickTextDraw( playerid, INVALID_TEXT_DRAW ) callback would act first instead of OnDialogResponse, so you have to press a second time to close the dialog (the problem is that they should be reversed). This should be reversed, dialogs appear on the first "layer" of the screen and textdraws appear under it. As a regular user, you would expect ESC to trigger dialog cancelling, not the textdraws which are under the dialog.

This can be partially reverted by scripting. But, again, not without storing lots of additional things and can't be made without a lot of mess (also, can't be made properly because we can't get the currently selected dialog listitem) !
1. This first method would need some GetPlayerDialogID/IsDialogOnScreen/GetPlayerDialogListItem and Get(Last)PlayerTextDrawHoverColor functions, but we don't have them, so we have to store them in additional arrays. We need to store last hover color to reapply SelectTextDraw correctly under OnPlayerClickTextDraw and then manually trigger OnDialogResponse with response = 0.
2. For the second method, the OnPlayerClickTextDraw callback should add another thing to the return values: actually cancelling the selection or not, so we wouldn't need to reapply SelectTextDraw, but we would still have to trigger the OnDialogResponse callback manually.

Currently, the fix would look like this (can't be well made anyway):

Code:

public OnPlayerClickTextDraw( playerid, Text:clickedid )
{
    if( clickedid == INVALID_TEXT_DRAW )
    {
        if( gDialogID[ playerid ] != NONE )
        {
            SelectTextDraw( playerid, gLastHoverColor[ playerid ] );
            ShowPlayerDialog( playerid, -1, 0, " ", " ", " ", " " );

            OnDialogResponse( playerid, gDialogID[ playerid ], 0, GetPlayerDialogListItem( playerid ), gDialogListItem_Info[ GetPlayerDialogListItem( playerid ) ] ); // but this last parameter behaves differently on different dialog styles, so it would need edge cases
        }
        return 1;
    }

    // rest of the callback

    return 0;
}

I find this to be pretty annoying and counter intuitive. What appears "above" on the screen should be cancelled first (so, the dialog needs to be cancelled first, not the textdraw selection). It has to be fixed, I noticed this problem before too but I didn't give too much attention to it, it always looked wrong anyway.

(sorry if there's any mistake in my explanation/grammar, it's 4AM here and did it pretty fast)

EDIT: Probably happens the same with SelectObject/EditObject. This should look like: cancelling dialog > cancelling textdraws selection > cancelling objects selection/editing (not sure if it is possible to be in the object selection/editing mode while you are also in the textdraw selection mode).

Re: SelectTextDraw and ShowPlayerDialog - cancelling with ESC logic problem - stabker - 13.11.2017

What if i tell you that you could simply cancel TD selection before showing dialog and restore after dialog response? Also don't allow TD selection whilst dialog is shown.

Re: SelectTextDraw and ShowPlayerDialog - cancelling with ESC logic problem - IstuntmanI - 12.12.2017

Quote:

Originally Posted by stabker

What if i tell you that you could simply cancel TD selection before showing dialog and restore after dialog response? Also don't allow TD selection whilst dialog is shown.

This isn't a nice workaround, especially on larger servers with tons of dialogs and all kinds of textdraws. It would be better to have the logic directly changed.