NightRoman wrote:Может быть это и полезно. Но до опыта я не знаю, зачем это нужно (редактор отображен особенно).
для согласованности, чтобы не было ситуации, когда апи говорит нам, что на экране редактор, а реально там панели. для единообразия, диалог в ve_read — под ним окно просмотра, в ee_read — панели. но нарисовать редактор можно и без событий, проблема не в этом. ещё мне показалось, что в вопросе есть непонимание, зачем при посылке ee_read нужен полностью сконструированный редактор? это мне показалось или нет?
John Doe wrote:zg wrote:3. EE_CHANGE. вот тут хуже всего. если один плагин в ee_read что-то поменяет, при запрете всех событий до конца ee_read, остальные плагины не получат нотификаций об этих изменениях. и это может быть очень критично.
А можно пример сценария, где это критично?
1. в энциклопедии написано, что ee_change приходит при изменении текста в редакторе. если вдруг он при каком-то изменении перестаёт приходить — это 100% баг. если хотелось какого-то другого поведения от этого события, то об этом надо было писать, когда оно предлагалось, а не вдруг сейчас.
2. напомню, что EE_CHANGE один раз ломалось, вместо посылки всем сделали только тем кто подписался. и тогда тоже казалось, что ничего в этом сильно критичного нет. а вдруг внезапно оказалось, что EdtFind начал файлы портить. но в тот раз это хоть было обосновано.
в целом повторюсь. запретить ee_redraw/ee_*focus до полного окончания ee_read — вообще не проблема. но вот ee_change запрещать нельзя. и вот для меня не очень понятно, если ee_change всё равно останется, то какой смысл в запрете ee_redraw/ee_*focus? в чём принципиальная разница?