Debugger says: You MUST NOT NEVER EVER use a modal dialog in a timer

fwilleke80

This post is deleted!

fwilleke80

Hmm, I can do the "to do" stuff inside the lambda, of course. But what would that change? The problem is, still, that the code is being called from MessageData::CoreMessage() (inside a CommandData, like in your example, was never a problem), and therefore opening the dialog causes the warning to appear, no matter what code comes after opening it.

And the other problem still persists, too: If I don't Wait() after enqueueing the lambda, the dialog doesn't even appear. And if I Wait(), Cinema freezes.

Maybe it's simply not possible to do anything with modal dialogs in code that's called from MessageData::CoreMessage, regardless of any threading stunts we could do?

Manuel

hi,
using wait or getresult is really strange i agree, but you don't need them.

I've added a MessageData and use a timer to trigger the CoreMessage. There i enqueue de job that is executed immediately,

The following code is not executed because g_inTimer is false. (the job is executed from main thread).

	if (g_inTimer)
	{
		DiagnosticOutput("You MUST NOT NEVER EVER use a modal dialog in a timer. Please run a job on the main thread (see job.h).");
	}

the MessageData i've added :

class TimerMessage_pc12545 : public MessageData
{
	virtual Int32 GetTimer(void);
	virtual Bool CoreMessage(Int32 id, const BaseContainer &bc);
};

Int32 TimerMessage_pc12545::GetTimer()
{
	return 10000;
}

Bool TimerMessage_pc12545::CoreMessage(Int32 id, const BaseContainer &bc)
{
	if (id == MSG_TIMER)
	{
		iferr_scope_handler
		{
			return false;

		};

		maxon::JobRef::Enqueue(
			[]() -> maxon::Result<void>
			{
				iferr_scope;
				pc12545_nodalDialog credentialsDialog;
				credentialsDialog.Open(-1, -1, 200, 200, true);

				if (credentialsDialog.GetResult())
				{
					const	maxon::String returnedString = credentialsDialog.GetPass() iferr_return;
					ApplicationOutput("you new password is @", returnedString);

				}
				else
				{
					ApplicationOutput("your password haven't been modified");
					return maxon::UnknownError(MAXON_SOURCE_LOCATION);
				}
				return maxon::OK;
				// ... do something with the password.
			}
		, maxon::JobQueueRef::GetMainThreadQueue()) iferr_return;


	}

	return true;
}

Cheers,
Manuel

fwilleke80

Hm, thanks. Well, in my case, I don't even use the MessageData's timer. I am simply reacting to a CoreMessage that is sent from another part of the plugin. And it seems, in that case g_inTimer is true. Is there a way to make it false?

My code looks basically similar to yours, I'm just listening to another message, not MSG_TIMER.

fwilleke80

Addition: I've also tried returning 0 from MessageData::GetTimer(), it changes nothing.

fwilleke80

And 2nd addition: How do you proceed when you actually need the credentials from the dialog in the code after the lambda? I can't move the whole plugin with all its components to a separate enqueued job, just because of the problem with modal dialogs.

I need to show the user the dialog, and get their input. I need things to wait until the user has closed the dialog, then I need the credentials and do stuff with it that is not part of the same lambda.

Manuel

hi,
I don't think the message i react to is important.

You can call whatever function you need inside the lambda. You can pass that function some parameters. This will be executed from the mainThread.
Once it's done, the lambda will send a CoreMessage and your plugins could react to that.

it's just like "hey job, do this for me and tell me once it's done"

Sorry i don't see where's the issu here, or at least i can't reproduce it.
Maybe you could send us some more information by email to keep it secret (as it's related to password etc) or code.

Cheers,
Manuel

fwilleke80

Sending another CoreMessage... interesting... I will try that, too. Thank you!

Manuel

hi,

did you tried out ?

Cheers,
Manuel

Manuel

hi,

I'll set this thread as solved without feedback from your side.

Cheers,
Manuel

fwilleke80

I did try it out, and did not experience any change in behavior. I guess it's rooted somewhere entirely else.

Manuel

arff, that's really strange, I'll send you a simple example and see if the error still happen on your system.