Confirm Dialog handler within IF...ELSE not working

[Steven]

I get this error:
LOG: Unexpected dialog encountered. Taking no action.

It works outside of the IF...ELSE.  Has anybody seen this?

[Keaegan]

Hello Steven,

After reviewing your previous tickets, it sounds like you are using radconfirm() to handle your confirm dialog. If this is the case, it cannot be used in code (such as the if...else you mentioned) because Javascript is not allowed to block the browser execution thread.

Moving the radconfirm() outside of the code (your if...else statement) should allow the command to function as expected.

This behavior is expected. You can read more about this feature at our ASP .NET demo for Alert, Prompt, Confirm.

Kind regards,
Keaegan
the Telerik team

[Steven]

I created a simple example of this scenario on a page where I am pretty sure radconfirm() is not being used:
http://www.javascripter.net/faq/confirm.htm
It does not work.
I have attached an image of the WUTS test script.

Have you tried creating a simple test like this where there is a Confirm Dialog handler within an IF...ELSE construct?

Thanks for looking into this.

[Keaegan]

Hello Steven,

Thank you for the additional data. I was able to reproduce this specific type of issue and have created bug ID 79275 to document this issue. I have forwarded the bug to our developers for them to review. I apologize that I do not have an ETA for when they will have a resolution for this issue.

For now, the best workaround is to not have the dialog handlers inside an If...Else statement.

Please feel free to keep the bug ID for your own records. If you have any questions about this issue, please let us know.

Best wishes,
Keaegan
the Telerik team

[Steven]

Hi Keaegan,

Thanks again for investigating this.  I understand an ETA is difficult to provide at this time but I want to reply to your suggestion to "not have the dialog handlers inside an If...Else statement".  Given the nature of the user interface I am testing this is difficult to do - most likely impossible.  It is a notebook-type control where the user conditionally proceeds to (and the code enables) subsequent tabs.  That is, there is incremental and conditional logic reflecting the multi-step workflow and along with it there are Confirm dialogs to make sure the user wants to proceed to the next step.  So if you could make this a relatively high priority it would be much appreciated.  I am guessing (many?) others will come across this issue.

Also, please let me know of any alternative approaches such as converting to code.

Regards,
Steve

[Keaegan]

Hello Steven,

If you have a more complicated work-flow in mind for the test, let's setup a GoTo Meeting so that you can show me what it is you are wanting the product to do. There may be another method to accomplish what you are wanting to do without using the IF...Else statements.

All below listed times are in UTC-6, and are 30 minute time slots:

Thursday:

1. 2:00PM-5:30PM

Friday:

1. 10:00AM-11:30AM
2. 2:00PM-5:30PM

Pick a 30 minute time slot from the above listed times and let me know, I'll setup a GoTo Meeting for us so we can review this issue more deeply with you.

I'll look for your reply.

Kind regards,
Keaegan
the Telerik team

[Steven]

OK - Thu 2PM UTC-6.
Thanks.

[Keaegan]

Hi Steven,

Just created the GoTo Meeting for 2:00PM (UTC -6) on Thursday, November 17th. You should be receiving the confirmation email shortly.

Best wishes,
Keaegan
the Telerik team

[Steven]

Follow-up to our meeting ...

As I mentioned to you, using TestAsStep(s) - which contains the Dialog Handler processing - within the IF...ELSE avoids the stated problem. 

(Related to this, I now know that using TAS's is a viable option for me after you informed me of the "Inherit Parent Data" option.  This was my preferred method anyway - rather than having huge tests.)

It still might be worth keeping the 79275 ticket open so that one is not forced to use TestAsStep when needing to use a Dialog Handler within a conditional path.

[Jason]

I'm piggybacking here because I've just now encountered the same issue - I was unable to successfully execute a "Handle Confirm Dialog" within a do-while loop.  However, once I made the affected steps into their own test and then inserted the test-as-step inside the while loop, my test executed as desired.

I appreciate this thread being here so I was able to come up with a good workaround, and I regularly abstract things into their own tests to be used as steps in other tests (it's about as close to using good object-oriented design as I can come while using the QA edition), so this workaround wasn't a huge departure for me.  However, it seems a bit cumbersome, and I too wonder about the progress of ticket 79275, since the issue doesn't seem to be fixed in the latest production release.

[Cody]

Hi Jason,

It turns out bug 79275 was closed because the IF ELSE was incorrectly crafted.

We still have a feature request open to support dialog handling within logical blocks e.g. IF ELSE. That is still open. I don't know when it will be implemented but I can guarantee it won't be within the next 6 months. We agree that having to use Test-as-step for dialog handling is not the optimum solution.

Best wishes,
Cody
the Telerik team