Если не ошибка, прошу подсказать где я напортачил.
Вызываю waDialog c параметрами
$(mydialog).waDialog({
'height' : '400px',
'width' : '660px',
'onClose' : function(f) {
$(this).remove;
},
'esc' : true,
});Сам mydialog имеет такую структуру
<div id="wadlg_new" style="display: block;">
<div class="dialog-content" id="db-dialog">
<div class="block">
<ul class="tabs" id="bf-tabs">
<li class="selected" mydiv="bf1"><a href="#">Первая вкладка</a></li>
<li mydiv="bf2"><a href="#">Вторая вкладка</a></li>
</ul>
<div class="tab-content ">
<div class="fieldgroup bf1" style="max-height:300px; overflow:auto;">
Очень длинный по вертикали бла-бла-бла
</div>
<div class="fieldgroup bf2">
Короткий по вертикали бла-бла-бла
</div>
</div>
</div>
</div>
<div class="dialog-buttons">
<input type="submit" value="Ок" class="button blue"> или <a class="cancel" href="javascript:void(0);">отмена</a>
</div>
</div>Суть проблемы: при загрузке страницы и клике на элементе открывающем waDialog он открывается нормально, т.е. нормальных размеров, на активной вкладке вертикальный скролл. Но если его закрыть по ESC и открыть снова, то его размер по вертикали стремится к полному размеру div'а с длинным по вертикали содержимым. Т.е. получается что между окончанием div со скроллом (div class="fieldgroup bf1") и <div class="dialog-buttons"> возникает значительный кусок пустого пространства. Глянув в html визуально обратил внимание что между первым и вторым кликом разнится размер по высоте <div class="dialog-window">, который, как я понимаю, генерится в недрах фреймворка.
10 комментариев
Нет, похоже все-таки я где-то напортачил, потому как по похожему принципу штатный waDialog (настройка столбцов в разделе Товары) отрабатывает нормально. Тему удалить не смог т.к. видимо слишком мало времени в настройках выставлено для редактирования/удаления. Но если кто навскидку увидит ошибку - буду признателен. Ну а нет - так сам поищу.
И все же проблема имеет место быть. В дополнение к вышеприведенному примеру, div c очень длинным бла-бла-бла должен быть напичкан структурами вида
Тогда при первом вызове высота <div class="dialog-window"> корректная, а при закрытии по ESC и последующих вызовах его высота стремится к высоте div с очень длинным бла-бла-бла.
Eсть более удачные решения диалоговых окон да еще и с шаблонизаторами, кривой js\css от wa стараюсь использовать по минимуму т.к. пару раз попадал в подобные ситуации - исправление\поиск проблемы отнимал больше времени чем сама разработка плагина.
Стараюсь поступать строго наоборот :) Если есть решение от WA - использую его. Если встречаются проблемы, которые не удается обойти - тогда да. Но таких пока не встречалось. Эта, пожалуй, первая, да и то интерфейсно порешать можно. А можно и так оставить, благо на практике такая последовательность действий не часто встречаться будет. Ну а если кто и пожалуется - на WA свалить можно ))) (про "свалить" шутка, если что) :)
Вот и еще один баг всплыл:
по логике если в методе waFiles::convert не указан параметр $target, то его значение должно совпадать с $file, а хрен там, а кроме того $target = $file вызывает ошибку.
Да ошибок-то везде хватает. Без них не бывает. Вопрос как к ним относиться - философский, не более. Я спокойно отношусь. Не, ну иногда можно конечно психануть, слюной побрызгать. Но если только иногда, и слюней не много. Так, для профилактики :) Убежден, что грамотное, лишенное эмоциональной составляющей описание ошибки, а в идеале и ее причин, намного более действенный способ воздействия на разработчика, и, как следствие, получения нужного результата (т.е. её исправления).
Вот только с Хабом что-то эта теория сбой дает ))))
Ну я так понимаю Вы филосовскими копаниями в коде занимаетесь, а не зарабатыванием денег, тогда такой подход уместен.
Одно другому не мешает
Спасибо за сообщение — проверим. Но лучше в виде отдельной темы в разделе баг-репортов, пожалуйста. Просто в комментариях можем и пропустить, а не хотелось бы.
И все же сам напортачил. Теперь уж точно. Пардон за панику :)