v4.1.0, 4.1.1:
Изменен сервер активации: cdn.fundata.fun Новый экшен "Индекс http клиента" Новый параметр GET/POST : "Асинхронный вызов" - Вызывайте запросы в новом потоке, без ожидания! OnErrorCallback, AfterRequestCallback принимает также (request, retry) объекты, как и BeforeRequestCallback. Выполнить JavaScript - Обновил редактор кода, теперь показывает подсказки API Impersonate. Обновил Crypto модуль (RSA) Добавил много подсказок к разному функционалу. По дефолту теперь Remote Build (Экономия веса проекта): https://github.com/Int64x86/moduleDll Много мелких правок.Ожидатель селекторов
-
@UserTrue Не не в Коим Случае не Удаляй, пох что там думают, я например в Закладочки склал и Примерно вижу где он может Облегчить мне жизнь мол :)))
Я на ваших Советах с Фоксом и ещё некоторых (споров ваших с Фэтспайсом мол ток).
Ты умный Чел и тебе вообще должно быть Пох :)))
-
@realmedvedev said in Ожидатель селекторов:
@FastSpace said in Ожидатель селекторов:
интерактив и ожидание кэша
Что за штуки? Первое - это эмуляция ожидания? А второе? Проблема эта задрала. В многопотоке, за частую, страницы просто отказываются прогружаться. Почитываю иногда форум, вижу тут кто-то говорит про 250, про 500 потоков. Я просто в осадочке. Как это все работает без ошибок.. Я всего 20 потоков, и все, понеслась - страницы не прогружаются, элементы не прогружаются. Большинство потоков заканчивается ошибкой из-за таймаутов
Чтобы такого не происходило нужны циклы ожидания.
Сначала делаешь какое-нибудь действие, если результат это действия будет загрузка страницы целиком, либо часть загрузки, то запускаешь цикл с интерактив и можно еще вайт кэш. Метод document.readyState и метод с кэшем в выполнить код wait_load (маска) . Можно погуглить.
Всё этот цикл завершается корректно и дальше можно работать с элементами. Не нужно вызывать их ожидание через "Проверить существование", плодить кучу if и т.д. 1 функция интерактив + вай кэш. Вызывать в тех местах где пошла загрузка страницы (например после клика на кнопку)
Работает почти в 95% случаев, кроме парочки сайтов. На такой случай у меня костыль на количество элементов на странице. -
@mansory333 через код в файле интерфейса
-
1.1 - улучшена проверка видимости
-
@FastSpace Что за wait caсhe, подкиньте ссылку пожалуйста
-
очень крутой модуль, спасибо большое, сам хотел для себя написать подобное)
-
@RoselieDesa Это фича BAS
Выполнить код.wait_load("*imgs.hcaptcha.com/*")!Так шаб будет ждать когда загрузятся пички от капчи.
-
@RoselieDesa said in Ожидатель селекторов:
@FastSpace Что за wait caсhe, подкиньте ссылку пожалуйста

-
@olegtut said in Ожидатель селекторов:
@UserTrue said in Ожидатель селекторов:
Самое интересное, что когда @olegtut сделал такой модуль, то никто не спорил.
Как никто? Fox обосрал мой модуль в первые же дни :)
Обосрал? Если хотите я могу не смотреть ваши модули
-
Протестировал модуль, он хороший. Понравилось, что у тебя можно кастомизировать параметры для поиска по base64.
Вообще говоря, они с моей нынешней версией не сильно похожи, потому что моя нынешняя принимает на вход массив селекторов, а у UserTrue инпуты. Вообще при разработке модуля у меня была неопределенность, как лучше сделать, и первая версия у меня была тоже с инпутами. Массив селекторов - скучно и не соответствует духу визуальности БАС, но и большое количество инпутов мусорят пространство. Поэтому если ты возьмешь на вооружение совет от Fox, будет замечательно:@Fox said in Ожидатель селекторов:
Проще было сделать один инпут с кнопками "добавить" и "удалить"
Фича с тем, чтобы плодить отдельные переменные мне не зашла. Они выходят из одного кубика, одного компонента, по всем канонам должен возвращаться объект. Кроме того, за пределами кубика в большом скрипте будет не наглядно откуда вообще вылезла новая переменная.
Если хотелось более осмысленных переменных, то можно же было сделать ключи объекта с таким же названием. Например, не [[WAITING_RESULTS]].sel1 , а [[WAITING_RESULTS]].myVarName , тогда в дальнейшем в скрипте было бы сразу понятно какому кубику должно принадлежать значение.И есть предложение, я не знаю, насколько оно хорошее и стоит ли его брать во внимание, сделать триггер-функцию на событие onfound. Т.е. по нахождению опред. элемента исполнить опред. функцию. Для этого можно сделать третье поле, где можно указать функцию исполнитель. У нас большинство действий сводятся к обнаружению элемента и совершений пачки действий, если этот элемент найден. Ну это так, мысли вслух.
В остальном модуль хорош и что понравилось - больше кастомизирован, чем мой.
-
@olegtut said in Ожидатель селекторов:
Поэтому если ты возьмешь на вооружение совет от Fox, будет замечательно:
Не вижу в этом смысла, я перенес кнопки для сохранения действия на верх модуля, чтобы не приходилось скролить, и в таком случае какая разница чем занятно пустое пространство внизу
-
@UserTrue said in Ожидатель селекторов:
Не вижу в этом смысла, я перенес кнопки для сохранения действия на верх модуля
Ну смотри сам, это твой модуль, ты и распоряжаешься им как хочешь. В первую очередь, люди создают модуль под себя, а уже потом в качестве энтузиазма делятся ими с другими
-
@olegtut said in Ожидатель селекторов:
@UserTrue said in Ожидатель селекторов:
Не вижу в этом смысла, я перенес кнопки для сохранения действия на верх модуля
Ну смотри сам, это твой модуль, ты и распоряжаешься им как хочешь. В первую очередь, люди создают модуль под себя, а уже потом в качестве энтузиазма делятся ими с другими
Да ладно?
:D -
Не тестировал, но сразу могу сказать, что однажды надоест тянуться мышкой далеко к этим visible check. Лучше поставьте их по середине, между временем ожидания и самим селектором, будет гораздо приятнее. У кого монитор может быть 21:9. Вы представляете, сколько мышкой придется протянуть, чтобы их поставить\снять? А если 32:9 ? Боюсь представить...
Поле timeout тоже можно уменьшить. Написать 2-3 цифры и иметь 95% остального места пустым? Тоже лишние телодвижения мышкой