LCObjectPost/Send callback issue with answer dialogs

[monte]

I'm not sure if this is an issue on other platforms but I've just had a fairly long and stressful support request about mergAccessory. I couldn't workout why the callbacks weren't coming in. Then I had an epiphany... the user had answer dialogs everywhere instead of put or some other log so I got rid of them and all of a sudden the messages were coming in. Should I just put this in the good to know box or can we fix it and queue messages until the answer dialog is dismissed.

[LCMark]

@monte: The answer dialogs (on mobile - just like desktop) essentially do a dispatching wait while the answer dialog is on screen. This means the messages should be being dispatched... However, you can't nest answer dialogs on iOS - if you call answer while one is displayed, the second request will return 'cancel' straight away. Thus I'm not clear from your description exactly what is happening - is it the callbacks weren't being dispatched, or that the answer dialogs in them (assuming that's where they were) weren't being shown? (because one was shown already).

[monte]

Ah.. It could be the latter... There was lots of answer dialogging ...

[monte]

Thinking about this some more... wouldn't having the handler wait with messages until the first answer dialog is dismissed be more robust? I think this is only going to be an issue for callbacks or send in time stuff but just cancelling out on subsequent dialogs could easily introduce some quirks into an app...

[LCMark]

The answer command does already work like that (MCScreenDC::popupanswerdialog). It shows the dialog, then does a dispatching-wait until the user clicks on it. The key here is that it is a 'dispatching' wait - meaning that messages are dispatched during the wait (which is the same on desktop). So, in this case, the answer dialog is being shown, then a message is arriving that pops up another answer dialog but the latter fails because one is already on screen.

[monte]

right, what I'm suggesting is the second answer command should behave like it has "wait until answer dialog 1 is done with messages" just before it... rather than cancelling out immediately. I think that would be closer to user expectations.

[DarScott]

answer ... with no messages

[Janschenkel]

Shouldn't that be

Code: Select all

answer ... without messages

instead?

Jan Schenkel.

[DarScott]

Yes! It should be consistent with move. And anything else I'm not remembering.

Simple and consistent. Thanks Jan!

Maybe there are commands that need this or should work if this is added.

[DarScott]

Perhaps somebody should say this. I fully recognize there are lots of styles of programming and lots of ways exploring new tools and components. And I know I'm weird in what I do. And I know this sounds patronizing and arrogant. And I know we all take what customers really do very seriously.

Is the use of answer in a callback typical?

[monte]

@DarScott Yes it may be atypical but these things will happen...

@Janschenkel that's an idea but how would it work on desktop where we need messages for the answer dialog stack to function?

[mwieder]

I think this is what Monte is asking, but...

Would "answer without messages" block messages or just queue them up and release them when the answer dialog is dismissed?
I can think of problem scenarios either way.

[DarScott]

This might be related to what I was mentioning in another context. It would be nice to have some blocking support. I am resigned to partial blocking, but it looks like there are cases in which it would be nice if only some messages (those related to the current operation) are processed and others are not.

I'm not sure that we "need" messages for the answer dialog to function on desktop, I think that is an implementation issue. I don't think there is any language feature that depends on it.

[monte]

@DarScott Implementation of the handlers in the answer dialog... how would you implement them without messages?

[DarScott]

@monte, I just skimmed over the dictionary entry for answer and I did not notice the word "handler". There is nothing there that requires that answer be implemented in LiveCode.

Now, I think it would be cool if it was. Of course, that is best if some mechanism for blocking is provided. That mechanism, in its simplest form, might be like this:

Code: Select all

lock messages except those for me
...
unlock messages

I don't know if that is really the right form. This should be able to expand to also except all those libraries this depends on. And maybe some others that promise to behave. But, to start with, maybe an explicit list is good.

Then with that "without messages" can be implemented.

And then with the same command, I can add blocking versions to my commands. (Or "without messages" versions.)