Password Dialog box crash

[iceman50]

 1) make a dlg box pop up for entering passwords
 2) close the hub frame right before a reconnect (what will happen is that as the HubFrame is closing a dialogue box for password input will come up but the frame is closed already so cancelling or even hitting ok will crash DC++)

 Using te steps above will 100% crash DC++ every single time

[iceman50 (bdcdevel)]

  DCPlusPlus.exe!HubFrame::onGetPassword() Line 554 + 0x2b bytes C++
  DCPlusPlus.exe!dwt::Application::dispatchAsync() Line 260 C++
  DCPlusPlus.exe!dwt::Application::dispatch() Line 190 + 0x7 bytes C++
  DCPlusPlus.exe!dwt::Application::run() Line 158 + 0x7 bytes C++
  DCPlusPlus.exe!SmartWinMain(dwt::Application & app) Line 65535 C++
  DCPlusPlus.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 287 C++
> DCPlusPlus.exe!__tmainCRTStartup() Line 547 + 0x1c bytes C
  kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
  ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
  ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes

[poy (poy)]

i can't reproduce, the dialog is modal as it should be so there is no way to close the hub window before closing the dialog itself. i tried shutting down the hub while the dialog was up but that didn't cause any problem either.

also your lines have a different offset than mine; what exactly is at line 554? does adding checks like [if (client)] or [if (client && client->isReady())] fix it?

[iceman50 (bdcdevel)]

Line 554 of HubFrame.cpp is as follows..

client->password(Text::fromT(linePwd.getValue()));

[eMTee (realprogger)]

Tests prove its possible that when HubFrame::preClosing is called the password dialog is beeing / already shown. When the dialog closed then the Client object is already destroyed in the hubframe destructor, that's why it crashes.
If its possible to check somehow that the window is beeing closed (even before preClosing called) then the dialog can be prevented to show using that way (beyond my competence)
If not, both of the two attached patch prevents the crash, choose the better looking one :)

[poy (poy)]

merged other bugs into this one as they are manifestations of the same set of problems, all formed by the fact that DWT dialog loops are "too smart": they keep running the main loop which, while otherwise brilliant and unique as far as i know in a Windows UI library, can lead to a few odd issues.

1) one top-level window shouldn't be allowed to display more than one modal dialog at the same time.

2) the parent of a dialog shouldn't be allowed to be closed until the dialog has been dismissed; or alternatively, the dialog should be closed right before closing its parent.

3) message boxes, which aren't as "smart" as our modal dialogs, should obey rules 1 & 2 as well.

[poy (poy)]

fixed in rev 2577 by taking advantage of the fact that the top-level window of a modal dialog is disabled. this creates slightly stricter rules than what the Win API would authorize in theory, but it's acceptable (and even necessary) for DWT.

note that by "top-level" i of course mean the top-most parent (not top-most owner) which could be either the main window or a modal dialog.

i reproduced several scenarios by lowering the reconnect delay to a hub that kept asking for a password, and toying with the "confirm app exit" / "confirm hub close" settings. all fixed here; let me know if there is still any similar issue.

[poy (poy)]

Fixed in DC++ 0.790.