@UserTrue Дело в том что может быть дело совсем в другом, потому что еще процесс обработки одного изображения долго происходит больше минуты, а весь шаблон я бы не хотел в общий доступ выкладывать
[[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга
-
@senerg said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
@uraabk said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Так если вы хорошо знаете яваскрипт, зачем вам Бас?
Не то чтобы хорошо, просто там получается быстрее, и что не знаешь можно быстро нагуглить. А тут попробуй нагугли, например, как сохранить файл с урл строчкой кода в басе. Хрен там. Да и пока эти кубики настроишь и с пробелами и скобочками разберешься...
Так если с Басом такие сложности, то не лучше ли найти что то более удобное, понятное? На что написано много гайдов...
-
@uraabk said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
найти что то более удобное, понятное?
Боюсь бесплатных или работающих вылеченных аналогов с таким же функционалом просто нет.
@allive said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Т.е. было много попыток и далеко не 20% удачные
К сожалению, тут вы правы.
-
@senerg said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
работающих вылеченных аналогов
Нужно больше ботов в сети, нужно больше ботов))
Бот в данном случае будете не ваше поделие, а ваш компьютер. Ну и вы соответсвеноbotnet
https://community.bablosoft.com/topic/5261/я-плачу-весь -
@sten30 said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Интересно, что ответ так и не дали.
Я первым же сообщением дал корректный ответ

Я решил проблему так - записываю CYCLE_INDEX в другую переменную, после этого задержка, и после вложенного цикла возвращаю номер обратно в CYCLE_INDEX .
Проще создайте перед циклом две переменных с значением
0, и внутри каждого цикла первым действием увеличивайте отдельную переменную. В такой конструкции не будет неожиданностей с переопределением. -
-
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Проще создайте перед циклом две переменных с значением 0, и внутри каждого цикла первым действием увеличивайте отдельную переменную. В такой конструкции не будет неожиданностей с переопределением.
Тут есть небольшая проблема.
Если в кастомном модуле в функции есть цикл, то код из кастомного модуля затрет переменную CYCLE_INDEX в коде пользовательского скрипта своим значением.
С другими подобными переменными такая же проблема.
Вероятно, надо в коде функции кастомного скрипта перед объявлением цикла проверять есть ли такая переменная(она может быть объявлена в коде пользовательского скрипта), если есть, то сохранять ее и восстанавливать значение до возврата из функции.
Причем нужно восстанавливать значение при любом поведении, в том числе если функция из модуля упадет, чтобы пользователь не увидел свои изменённые переменные и долго не думал "что за фигня тут у меня".
Это если пользователь решит обернуть вызов функции из модуля в ошибку.Выглядит жутким хаком.
Если кому то надо, вот список глобальных переменных, не всех их надо сохранять и восстанавливать.
VAR_CYCLE_INDEX VAR_FOREACH_DATA VAR_FOR_EACH_CSS VAR_FOR_EACH_MATCH VAR_FOR_EACH_XPATH VAR_WAS_ERROR VAR_LAST_ERROR VAR_ERROR_ID VAR_CYCLE_INDEX VAR_FOREACH_DATA VAR_FOR_EACH_CSS VAR_FOR_EACH_MATCH VAR_FOR_EACH_XPATH VAR_WAS_ERROR VAR_LAST_ERROR VAR_ERROR_IDОбщую идею, как это можно делать, можно почитать тут:
https://community.bablosoft.com/topic/25851/проблема-при-вызове-функции/30 -
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Проще создайте перед циклом две переменных с значением 0, и внутри каждого цикла первым действием увеличивайте отдельную переменную. В такой конструкции не будет неожиданностей с переопределением.
Тут есть небольшая проблема.
Если в кастомном модуле в функции есть цикл, то код из кастомного модуля затрет переменную CYCLE_INDEX в коде пользовательского скрипта своим значением.
С другими подобными переменными такая же проблема.
Вероятно, надо в коде функции кастомного скрипта перед объявлением цикла проверять есть ли такая переменная(она может быть объявлена в коде пользовательского скрипта), если есть, то сохранять ее и восстанавливать значение до возврата из функции.
Причем нужно восстанавливать значение при любом поведении, в том числе если функция из модуля упадет, чтобы пользователь не увидел свои изменённые переменные и долго не думал "что за фигня тут у меня".
Это если пользователь решит обернуть вызов функции из модуля в ошибку.Выглядит жутким хаком.
Проблема переменных BAS в модулях имеют более глобальные последствия, ведь многие используют в действиях стандартные названия переменных, а затем из этих действий создают модули, которые и вызывают проблемы перезаписи переменных со стандартными названиями. Об этой проблеме уже есть тикет, есть несколько возможных решений, но пока единственный надёжный способ, это в ручную править код заменяя переменные BAS на переменные js (var VAR_CYCLE_INDEX и т.д.)
-
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
проблема переменных BAS в модулях имеют более глобальные последствия
Да. Но основная проблема не в существующем поведении, а в том, что нет документации на этот счет, пользователи расшибают лбы об стенку самостоятельно.
И нет инструкция с обходными путями. Пользователи сами придумывают костыли, как избежать этого.
Хотя логика простая - если до вызова функции некий список переменных был объявлен(CYCLE_INDEX, VAR_FOREACH_DATA, etc), то перед вызовом функции сохранять их значения и восстанавливать после возврата.
Вот прямо сейчас я это и делаю на основании твоего же кода.
P.S.
У модулей должен быть своя видимость области переменных, это решит почти все проблемы. -
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
проблема переменных BAS в модулях имеют более глобальные последствия
Да. Но основная проблема не в существующем поведении, а в том, что нет документации на этот счет, пользователи расшибают лбы об стенку самостоятельно.
И нет инструкция с обходными путями. Пользователи сами придумывают костыли, как избежать этого.
Хотя логика простая - если до вызова функции некий список переменных был объявлен(CYCLE_INDEX, VAR_FOREACH_DATA, etc), то перед вызовом функции сохранять их значения и восстанавливать после возврата.
Вот прямо сейчас я это и делаю на основании твоего же кода.
P.S.
У модулей должен быть своя видимость области переменных, это решит почти все проблемы.Не уверен, что область видимости можно ограничить в BAS. Можно поступить с переменными, как с функциями - добавить опцию, что бы генерировать длинные случайные названия переменных, заменяя используемые в функции при создании модуля
-
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Не уверен, что область видимости можно ограничить в BAS
Пользователям нельзя, разработчику думаю можно все.
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Можно поступить с переменными, как с функциями - добавить опцию, что бы генерировать длинные случайные названия переменных
Кстати идея, задумался не написать ли мне сейчас скрипт, который делает post-process модуля, превращая все переменные внутри функции модуля в случайные названия.
-
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Пользователям нельзя, разработчику думаю можно все.
Если реализация изоляции переменных BAS в модуле будет требовать больших изменений в текущей логики работы BAS, то разработчик этого делать не будет.
Кстати идея, задумался не написать ли мне сейчас скрипт, который делает post-process модуля, превращая все переменные внутри функции модуля в случайные названия.
Да, я вроде даже выкладывал скрипт для замены имён переменных в модуле, не помню только где именно.
-
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Да, я вроде даже выкладывал скрипт для замены имён переменных в модуле, не помню только где именно.
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
это в ручную править код заменяя переменные BAS на переменные js (var VAR_CYCLE_INDEX и т.д.)
Если в файле engine.js заменить все переменные, которые начинаются с VAR на что-то другое, то это пройдет без побочных эффектов?
было:
VAR_LOG_PREFIX = _function_argument("_log_prefix") var json = JSON.parse(native("filesystem", "fileinfo", VAR__DIRECTORY_PATH)) VAR_FILEINFO_EXISTS = json["exists"]стало:
_LOG_PREFIX = _function_argument("_log_prefix") var json = JSON.parse(native("filesystem", "fileinfo", __DIRECTORY_PATH)) _FILEINFO_EXISTS = json["exists"] -
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
это в ручную править код заменяя переменные BAS на переменные js (var VAR_CYCLE_INDEX и т.д.)
Если в файле engine.js заменить все переменные, которые начинаются с VAR на что-то другое, то это пройдет без побочных эффектов?
было:
VAR_LOG_PREFIX = _function_argument("_log_prefix") var json = JSON.parse(native("filesystem", "fileinfo", VAR__DIRECTORY_PATH)) VAR_FILEINFO_EXISTS = json["exists"]стало:
_LOG_PREFIX = _function_argument("_log_prefix") var json = JSON.parse(native("filesystem", "fileinfo", __DIRECTORY_PATH)) _FILEINFO_EXISTS = json["exists"]По идее должно работать, однако вы меняете одни глобальные переменные js на другие.
-
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
По идее должно работать, однако вы меняете одни глобальные переменные js на другие.
Было "VAR_", стало без него.
А это значит, что стандартным способом пользователь не сможет случайно затереть свою переменную из-за модуля, которую он также создал стандартным способом(BAS-переменная).
Или надо var VAR_Buu и таким обзором они станут локальными javascript переменными ?
-
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
По идее должно работать, однако вы меняете одни глобальные переменные js на другие.
Было "VAR_", стало без него.
А это значит, что стандартным способом пользователь не сможет случайно затереть свою переменную из-за модуля, которую он также создал стандартным способом(BAS-переменная).
Я об этом и говорю, смысл в том, что к переменным модуля можно будет получить доступ извне. Если цель обезопасить пользователя от замены существующих переменных, то достаточно добавить длинную случайную строку (можно unixtime для уникальности добавить). Это будет более безопасно, чем удолять
VAR_ -
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Я об этом и говорю, смысл в том, что к переменным модуля можно будет получить доступ извне. Если цель обезопасить пользователя от замены существующих переменных, то достаточно добавить длинную случайную строку (можно unixtime для уникальности добавить)
На всякий случай уточняю еще раз.
Было:
VAR_LOG_PREFIX = _function_argument("_log_prefix")Стало:
Вариант 1:
var VAR_LOG_PREFIX = _function_argument("_log_prefix")Вариант 2:
VAR_LOG_PREFIX_some_string_name_of_module_for_example = _function_argument("_log_prefix")Вариант 3:
var VAR_LOG_PREFIX_some_string_name_of_module_for_example = _function_argument("_log_prefix")По идее, второй вариант можно встроить в генератор модулей.
Тогда у пользователя останется возможность даже обратится к переменной модуля, если он захочет.
И в git не будут светиться лишние изменения, так как нет ничего случайного и нет мусорных diff. -
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
По идее, второй вариант можно встроить в генератор модулей.
Тогда у пользователя останется возможность даже обратится к переменной модуля, если он захочет.
И в git не будут светиться лишние изменения, так как нет ничего случайного и нет мусорных diff.Да
-
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
По идее, второй вариант можно встроить в генератор модулей.
Тогда у пользователя останется возможность даже обратится к переменной модуля, если он захочет.
И в git не будут светиться лишние изменения, так как нет ничего случайного и нет мусорных diff.Да
Так я и сделаю у себя, пока напишу скрипт для замены.
Огромное спасибо, что подсказал все варианты, что могут быть.