Problem with MMX in D13.

[Ian Branch 142]

When I start D13 with the latest MMX, 16.0.8.59, installed I getthis message but inability to click on Yes or No, justthe busy cursor:

I have to abort D13.

15.0.7.52 installs and runs without issue.

Edited yesterday at 04:09 AM by Ian Branch

[Uwe Raabe 2185]

The message is expected. It basically asks if it should copy existing V15 settings to V16.

 

I assume the 15.0.7.52 is a typo and should read 16.0.7.52 and refers to the latest beta version?

That didn't make use of separate V16 settings and silently used the V15 ones, so that message is not triggered.

 

Back to the actual problem. As there were quite a couple of downloads and installations since the webinar and I'm not getting tons of complaints like the above, there must be something in your environment triggering that.

 

The code responsible for that message is:

    if MessageBox(0, PChar(Format('Use MMX Code Explorer V%d settings?', [MidexVersion - 1])),
                  'MMX Code Explorer', MB_YESNO or MB_ICONQUESTION or MB_TASKMODAL) <> IDYES then Exit;

Because of MB_TASKMODAL any windows shown by other threads can be shown and worked with, so I guess some other thread is showing a window not visible to us in a way that blocks input to the MMX message.

 

The one thing visible on the screenshot is GExperts for Delphi 12  . Just to rule things out, can you please try without that?

[Ian Branch 142]

1 hour ago, Uwe Raabe said:

I assume the 15.0.7.52 is a typo and should read 16.0.7.52 and refers to the latest beta version?

Yes.  Apologies.

1 hour ago, Uwe Raabe said:

The one thing visible on the screenshot is GExperts for Delphi 12  . Just to rule things out, can you please try without that?

Yep.  That fixed it.

 

P.S.  Installing GExperts after MMX works.  No loading/starting issues.

Edited yesterday at 09:11 AM by Ian Branch

[Kas Ob. 156]

1 hour ago, Uwe Raabe said:

The code responsible for that message is:

    if MessageBox(0, PChar(Format('Use MMX Code Explorer V%d settings?', [MidexVersion - 1])),
                  'MMX Code Explorer', MB_YESNO or MB_ICONQUESTION or MB_TASKMODAL) <> IDYES then Exit;

Because of MB_TASKMODAL any windows shown by other threads can be shown and worked with, so I guess some other thread is showing a window not visible to us in a way that blocks input to the MMX message.

I have a theory on how this might why this happen, which doesn't involve invisible windows.

 

That MessageBox message doesn't have an owner window handle meaning Applicaiton.ProcessMessages might easily cause this halt of messages processing for this very message box as it will prefer the splash screen, all you need is Modal form and MessageBox with MB_TASKMODAL to enforce the conflict while there is no owner, and of course spray a little of back ground thread calling and might be trying to synchronize with the main thread, and if there is Applicaiton.ProcessMessages somewhere from background thread then messages will not be answered.

[Uwe Raabe 2185]

Yep, that sounds like a valid scenario for triggering the problem.

 

I also cannot explain why the code is as it is - I just kept it as it was when I took over.

 

Do you have a suggestion which window handle I could use as the owner window?

Edited yesterday at 09:22 AM by Uwe Raabe

[Kas Ob. 156]

18 minutes ago, Uwe Raabe said:

Do you have a suggestion which window handle I could use as the owner window?

None as it might cause worse behavior, i am sorry i don't recall testing all the cases with such combination, BUT..

 

I think MB_APPLMODAL instead of MB_TASKMODAL might the solution with no owner handle, in case that failed then keep using MB_APPLMODAL and use any, like any handle you can access at that stage, on one condition though the handle must be a Delphi form handle.

[Kas Ob. 156]

But thinking more, i think the whole loading setting and blocking for user input, might be a problem, what about dropping the loading of setting in this case and delay the question until the IDE fully loaded, then ask the user his input then ask to fully IDE restart, this should happen rarely but will remove any similar and problematic behavior for good.

[Kas Ob. 156]

Thinking more and running more twisted tests on the IDE, the thing is the suggestion to delay the question might be not simple and require a lot of modification, so ..

 

If you can access Application.Handle and pass it as owner handle then it should solve this for good, for both M B_APPLMODAL and MB_TASKMODAL, this put all background threads in order and act as the Application should act.

 

And by "can access" i am assuming that message is coming form a DLL and not from the package (PBL), but in both cases i am sure you can find a solution.