Dialog while loop processes msgs generated before the dialog is shown

After spending longer than I am prepared to admit trying to find the cause of a bug in DopStack, I have realised that if you change the state of a checkbox control after the dialog is created and before the dialog is actually shown, the while loop will receive a "click" message for that change.

This button demonstrates - as the dialog opens a message will be sent to the Script Log, when the intention is for it only to output the message once the user clicks the checkbox.

Changing the line:
if (msg.event == "click" && msg.control == "check") {
to
if (msg.event == "click" && dlg.Control("check").focus == true) {
solves this.

Is this how it's meant to work?

Checkbox Test.dcf (2.0 KB)

Script

function OnClick(clickData)
{
	var dlg = DOpus.Dlg();
	dlg.title = "Test";
	dlg.template = "dialog1";
	dlg.detach = true;
	dlg.Create();

	dlg.Control("check").value = true;

	DOpus.ClearOutput();
	
	dlg.Show();

	while (true) {
        var msg = dlg.GetMsg();
        if (!msg.result) break;

		if (msg.event == "click" && msg.control == "check") {
			DOpus.Output("Got a click message");
		}
    }
}

That's something Windows does (which we don't do anything to filter out).

There are a few ways to tackle it.

The easiest is probably to check what the control's current state is when you get the event, rather than treat the event as a toggle on what your code thought the current state was.

1 Like

Thanks.

That won't work in this case though. I have two text boxes which change the style of the listView display (details/icon and grouping). Regardless of the state of the checkboxes, true or false, they need to run the function which updates the listview. This function is run once when the dialog first opens, and then only if the user clicks the checkboxes. The result of this was that I had the listview populating 3 times, once by design and twice by setting the checkboxes.

No matter, using the .focus method works.

You could have a variable tracking the current state, so then you know if it has changed or not.

Checking focus should also work, and saves doing that. I don't think a control can have focus before the dialog is shown so that should be fine, as long as you don't programatically change the checkboxes after the dialog appears.

Yep, focus is now working fine. Will keep the variable in mind but with this particular piece of code, the state of the checkbox is irrelevant, it's the fact that it's been clicked that's important. It's state is checked later.

I guess a variable could still be used to identify if this is the first time the "click" has occurred and filter on that but with focus working, I think KISS is the better option. :smiley:

Thanks for clearing that up.

1 Like