Martin Vermeer <[EMAIL PROTECTED]> writes: > > // FIXME! Should check that the dialog IS an inset dialog. > - dialog->show(data); > open_insets_[name] = inset; > + dialog->show(data); > > That seems rather clear to me. As I understand (Angus would know) this > open_insets_ table keeps track of which insets have their dialog open, > so it doesn't try to open the same dialogue a second time.
It looked clear to me also, before I scanned the code for uses of getOpenInsets() ... ;-) > > Before the patch, the first opening process starts before the dialog is > registered, and as it takes a little time (especially the first time, > when the code has to be loaded into memory), the second click manages to > start a second opening process *for the same inset* -- a race condition. I found out that the code for Inset::showDIalog() doesn't use getOpenInsets(), so it shouldn't matter :-( GetOpenInsets() is only used for LFUN_DIALOG_APPLY and LFUN_INSET_APPLY. I still get a crash, but now it's related to the previews... another source of multithreading. So I guess the race condition is there, we just haven't figured out its exact shape yet. Ciao /Andreas
