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

[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.