When run on Ipad, program will lock up after display of MessageDlg when you click the button.

Now move the button up 50 pixels or more from the bottom and rerun program.
MessageDlg works properly.

Anyone able to re-produce this issue.

The reason I do not want to use the Async Message Dialog functions is that the dialog remains up after the user clicks the YES, NO or CANCEL buttons until the code that runs in the Async procedure is completed. For long running processes this appears to the user as a locked up application.

The reason I do not want to use the Async Message Dialog functions is
that the dialog remains up after the user clicks the YES, NO or
CANCEL buttons until the code that runs in the Async procedure is
completed. For long running processes this appears to the user as a
locked up application.

Then that is a bug that needs to be reported to Embarcadero. The
documentation clearly states that the async procedure is not supposed
to run until after the dialog box is closed.

The reason I do not want to use the Async Message Dialog functions is
that the dialog remains up after the user clicks the YES, NO or
CANCEL buttons until the code that runs in the Async procedure is
completed. For long running processes this appears to the user as a
locked up application.

Then that is a bug that needs to be reported to Embarcadero. The
documentation clearly states that the async procedure is not supposed
to run until after the dialog box is closed.

--
Remy Lebeau (TeamB)

Thank you the feeback Remy, But I was hoping the someone else can confirm this issue before I file a QC report. If multiple users confirm the same issue, Embarcadero might devote more time and resources to resolving it. That being said, I will create a QC report.

The reason I do not want to use the Async Message Dialog functions is
that the dialog remains up after the user clicks the YES, NO or
CANCEL buttons until the code that runs in the Async procedure is
completed. For long running processes this appears to the user as a
locked up application.

Then that is a bug that needs to be reported to Embarcadero. The
documentation clearly states that the async procedure is not supposed
to run until after the dialog box is closed.

--
Remy Lebeau (TeamB)

Thank you the feeback Remy, But I was hoping the someone else can confirm this issue before I file a QC report. If multiple users confirm the same issue, Embarcadero might devote more time and resources to resolving it. That being said, I will create a QC report.

Report Created RSP-19450

Edited by: William Brookfield on Nov 30, 2017 8:43 AM

Hello,

you may work around this by starting a short timed TTimer in that async
proc and put your code in that OnTimerEvent.

you may work around this by starting a short timed TTimer in that
async proc and put your code in that OnTimerEvent.

Instead of a timer, I would use a custom window message with
PostMessage() on Windows, or a cross-platform solution is to use
TThread.CreateAnonymousThread() + TThread.Queue(...), or
TThread.ForceQueue() in Tokyo and later.

you may work around this by starting a short timed TTimer in that
async proc and put your code in that OnTimerEvent.

Instead of a timer, I would use a custom window message with
PostMessage() on Windows, or a cross-platform solution is to use
TThread.CreateAnonymousThread() + TThread.Queue(...), or
TThread.ForceQueue() in Tokyo and later.

--
Remy Lebeau (TeamB)

I appreciate the suggestions and both a timer or a PostMessage would work, But, they are HACKS to get around that issue that the Async message Dialog feature is broken. If you have many prompts in your program for a user to decide to do this or that, It would require a lot of re-design to accommodate all the message dialog's even if you created a single post message event handler. I have confirmed that this issue also occurs on IOS 10.3.3 as well as IOS 11.1.2 both 64 and 32 bit (Debug and Release builds)

you may work around this by starting a short timed TTimer in that
async proc and put your code in that OnTimerEvent.

Instead of a timer, I would use a custom window message with
PostMessage() on Windows, or a cross-platform solution is to use
TThread.CreateAnonymousThread() + TThread.Queue(...), or
TThread.ForceQueue() in Tokyo and later.

--
Remy Lebeau (TeamB)

I appreciate the suggestions and both a timer or a PostMessage would work, But, they are HACKS to get around that issue that the Async message Dialog feature is broken. If you have many prompts in your program for a user to decide to do this or that, It would require a lot of re-design to accommodate all the message dialog's even if you created a single post message event handler. I have confirmed that this issue also occurs on IOS 10.3.3 as well as IOS 11.1.2 both 64 and 32 bit (Debug and Release builds)

I was hoping the another user can confirm this issue.

It has been a week since I posted the QC Report and no activity from Embarcadero on this issue. Would really like to know if anyone else has experienced or can confirm this issue. This would seem to me to be a major bug.

It has been a week since I posted the QC Report and no activity from Embarcadero on this issue. Would really like to
know if anyone else has experienced or can confirm this issue. This would seem to me to be a major bug.

I've made a comment on the report that includes a possible workaround.

It has been a week since I posted the QC Report and no activity from Embarcadero on this issue. Would really like to
know if anyone else has experienced or can confirm this issue. This would seem to me to be a major bug.

I've made a comment on the report that includes a possible workaround.

It has been a week since I posted the QC Report and no activity from Embarcadero on this issue. Would really like to
know if anyone else has experienced or can confirm this issue. This would seem to me to be a major bug.

I've made a comment on the report that includes a possible workaround.

It has been a week since I posted the QC Report and no activity
from Embarcadero on this issue. Would really like to know if
anyone else has experienced or can confirm this issue. This
would seem to me to be a major bug.

I've made a comment on the report that includes a possible
workaround.