С помощью невероятно полезной возможности создавать пользовательские блоки CODE, это уникальный инструмент и с его помощью можно решить ЛЮБУЮ временную недоработку программы. Именно так я и делаю. Если чего-то нет пока в программе, если что-то работает не так или вылетает... делаю пользовательский блок, пишу туда свой рабочий код и проблема решена.
Но уникальный модификатор, который дописывается переменным и параметрам, ставит огромные и толстые палки в колеса.
Я уже писал по поводу проблем с монитором ( http://forum.flprogwiki.ru/viewtopic.php?f=5&t=672 ), в программе нет блока для этого монитора, я сделал свой блок, но код монитора использует спецификатор extern, и переменную, которую он использует нельзя изменять "Спецификатор extern сообщает компилятору, что следующие за ним типы и имена переменных объявляются где-то в другом месте." В связи с этим я не раз просил автора убрать с пользовательского кода уникальный модификатор, или хотя бы сделать возможность выбора добавлять модификатор в этом блоке или нет!
Но с монитором я уже смерился, после компиляции вручную удаляю добавленный модификатор и заливаю в плату. Хотя и крайне напряжно при тестировании программы, когда заливать приходится несколько раз в день.
Теперь добавилась еще проблема с этим модификатором. Как известно, блок для ESP8266 временно не работает. Но это не проблема, я пишу пользовательский блок и успешно пользуюсь этим модулем. И блок прекрасно работает, если нужно передать что-то одно 1 раз за цикл программы. Но так же возникает проблема с уникальностью модификатора в переменных.

Проблема в следующем: Мне нужно в определенный момент отправить какие-то данные на роутер. И эта эта отправка должна производиться в разное время, с разными параметрами и разными данными... Поэтому нужно писать минимум 2 блока для этого модуля. 1 блок для определения переменных, инициализации и подключения роутера, 2-й блок для отправки данных в нужный момент, 3-й блок для отправки данных в свой нужный момент и т.д.... Но если так сделать, то в 1-м блоке переменным дописывается один модификатор, а в 2-м, 3-м ... этим переменным дописывается другой модификатор, и естественно компилятор получает разные (не декларированные) переменные! Ну такое править, это уже слишком. При тестировании и модуль иметь не захочешь...
Пробовал писать все в одном блоке, но тогда смысл программы почти теряется и работает не так как нужно. А если делать чтоб работало так как нужно, тогда весь код лучше написать вручную 
Уникальным модификатором автор программы пытается решить проблему уникальности переменных для автора проекта. Но если у меня (автора проекта) и возникнет такая проблема, я решу ее 1 раз и забуду, а при таком раскладе приходится с каждой компиляцией вручную править кучу кода!!!
Умоляю автора убрать добавление уникального модификатора или сделать возможность выбора.

P.S. Ну и заодно о глюке с разрешением записи пользовательского кода CODE. Вход En то появляется то исчезает Если даже и воспользоваться им, работает не корректно, т.е. не срабатывает на разрешение. Но это не проблема, это так попутно, я не пользуюсь встроенным входом разрешения, я использую свой, на вход добавляю специально переменную En. В начале кода пишу if (En) {  и далее код

AlexRyzh писал(а):С каждой компиляцией вручную править кучу кода!!!Умоляю автора убрать добавление уникального модификатора или сделать возможность выбора.

Мольбы скорее всего не помогут . Нужно чтоб "голосовалка" давала 400-500 за раз , в противном случае велик шанс впасть в немилость или получить стандартную отмазку - "я пока не готов" или " не хватает времени, может когда-нибудь. "

Отмазка "не хватает времени", и "я пока не готов" очень хорошо помогает, в оссобенности когда она соответствует действительности. Но это так - лирика.
Теперь серьёзно. По поводу идентификатора. Я действительно много думаю над этой проблеммой, и планировал произвести серьёзную доработку пользовательских блоков в комплексе. Для чего нужен идентфикатор? В основном для возможности неоднократного применения блока в проекте. Что бы при повторном использовании не было повторной реинициализации переменных.
Что я придумал и могу предложить в качестве решения. В свойствах блока создается новая галочка "Только для однократного применения" (ну или что то там подобное). При установке этой галочки уникальные идентификаторы не проставляются совсем, что есть в блоке, то в таком и виде попадает в скетчь. При этом программа не позволит повторно вставить такой блок в проект если его экземпляр уже присутствует в проекте. На плечи разработчика блока ложится контроль возможности совпадения имён переменных с другими блоками в проекте. Для этого и существует в редакторе блока пользователя генератор уникального числа который можно использовать при создании имён переменных.
Если такой вариант устроит - то я постараюсь, если успею в текущей версии это реализовать. (опять отмазка - времени не хватает))) Я правда ещё работаю на основной работе, но это не важно))))

Галочка в полне устроит. По умолчанию пусть стоит. Пока "стоит" ) ,идентификаторы дописываются, снимаем и разруливаем сами. При снятии предупреждение на всякий случай.

P.S. Отмазка "нехватает времени" особенно когда не готов, - помогает в любом случае!!! (шутка)

Вполне устроит такая галочка. Но лучше вообще убрать модификатор. Как я уже говорил, если с модификатором не работает что-то из-за этого модификатора, то это вина РАЗРАБОТЧИКА!!! Зачем Вам этот лишний гемор? В описании блока предупредить пользователя о самостоятельном контроле уникальности переменных. И все, дальше проблема пользователя! 
Все равно блок CODE работает не корректно во многих ситуациях ( и сохранение иногда не корректно, и код если с ошибкой, блок ошибку не видит). и только после попытки компиляции выявляется ошибка в коде. Но тут легко, вернулся в код 1 раз исправил и забыл!!!
Я лично всегда буду ставить эту галочку в пользовательском блоке КОДА.

И толку мало от того, что я могу вставить блок С ИДЕНТИФИКАТОРАМИ 2 раза в проект???
Вот что получается. Как поведет себя программа после такой компиляции??? Но при этом ни блок, ни компилятор ругаться не будут. Компилятор скушает, то что ему дал и будет лагать!
А при таком раскладе (когда уникальность будет упущена автором), компилятор выдаст ошибку. Опять же 1 раз ее нашел, исправил, и забыл! Спасибо разработчику за понимание и нелегкий труд 

AlexRyzh писал(а):Но лучше вообще убрать модификатор.

А если блок планируется использовать более одного раза. Например расчет чего то повторяющегося. Какая ни будь сложная математика например.  Или работа с массивами не покрытая стандартными блоками. Что тогда делать? под каждый вызов писать отдельный блок?

dekorator писал(а):При установке этой галочки уникальные идентификаторы не проставляются совсем, что есть в блоке, то в таком и виде попадает в скетчь.

Это очень круто!!! было бы. Тогда можно создать один пользовательский блок для определения переменных и начальных установок для всех блоков. А другие блоки делать только с исполняемым кодом. 
Может не всем и не всегда это удобно, но мне кажется так будет довольно удобно и понятно.

Добавлено (13.04.2016, 12:54)
---------------------------------------------

AlexRyzh писал(а):А если блок планируется использовать более одного раза. Например расчет чего то повторяющегося. Какая ни будь сложная математика например.  Или работа с массивами не покрытая стандартными блоками. Что тогда делать? под каждый вызов писать отдельный блок?

Тут Вы правы. Но как видно из моего поста выше - палка о двух концах.
Поэтому самый лучший выход - галочка. Чтоб пользователь решал быть уникальному модификатору или нет.

support писал(а):если блок планируется использовать более одного раза.  Что тогда делать? под каждый вызов писать отдельный блок?

В классическом программировании есть понятие "Процедура и Функция" описываются однократно, а используются многократно.
Может в этом направлении надо идти. Входа блока это параметры для процедуры или функции.

И все таки или я чего-то не понимаю... или одно из двух.
При вставке блока КОДЕ несколько раз переменные плодятся пропорционально. Это невероятно громоздкий код ради 2-х - 3-х переменных. Кроме того в боке есть и установочные параметры, которые тоже тоже плодятся как грибы. Мое мнение такое, что в любом случае блок КОДЕ нельзя вставлять в проект 2 раза. (и более). Кроме того, представим ситуацию ( ну образно, как буд-то такое может быть), когда программист пишет проект для Ардуино и при этом даже не знает что есть программа FLProg. Как же ему тогда быть с этими проблемами?

support писал(а):расчет чего то повторяющегося. Какая ни будь сложная математика например.  Или работа с массивами не покрытая стандартными блоками.

Ночутье мне подсказывает что он напишет нужный код, который получится не таким громоздким с повторяющимися переменными...  и вот этот код можно будет вставить в блок, и блок вставить в проект 1 раз!
Это не утверждение, это лично мое понимание происходящего... делюсь мыслями 
P.S.  И еще, лично мое мнение лучше убрать добавление модификатора, пока не придумана заветная галочка
А придумается галочка, тогда и модификатор прилепить, вдруг кому пригодится

Блоки пользователей  на FBD и LAD так примерно и работают. Они компилируются в функции, для блока формируется структура описывающая его входа, выхода и переменные. Это аналогично DB - шкам у сименса. Для каждого вызова блока создаётся инстанс этой структуры. При вызове блока в этот инстанс записываются входные данные, он передается функции , после того как функция отработала - из структуры по необходимости забираются данные.
Ну в общем идея слизана из организационных блоков Step-7

AlexRyzh писал(а):P.S. И еще, лично мое мнение лучше убрать добавление модификатора, пока не придумана заветная галочка smile

Если все будет хорошо, и меня сильно на работе не загрузят "заветная галочка" появится в следующей версии. Я уже всё продумал. Осталось реализовать. Версия выйдет в через несколько дней.

Заветная галочка готова.

Бог услышал мои молитвы!!!

А за это респект!!!! Спасибо огромное человеческое

Пример Функции

Alex16 писал(а):Пример Функции

Спасибо. Теперь я могу сделать удобные блоки для своего дисплея. В 1-м блоке прописать установки для дисплея и функцию вывода на экран, а для каждого экрана блок с кодом, который принимает переменные и отправляет их в функцию.
Думаю будет удобно первую плату создавать с именем "Setups_Functions progect" и туда вставлять соответствующие блоки. А исполнительные блоки, которые будут использовать указанные переменные, параметры, функции,  вставлять в проекте где удобно. И НИКАКОЙ уникальный модификатор не помешает тесной связи между такими блоками   
P.S. И еще не дает покоя вопрос: Это как должен выглядеть блок CODE с уникальным модификатором, чтоб его можно было вставлять в проект несколько раз, без паразитного размножения переменных

AlexRyzh, поделитесь пожалуйста блоком монитора готовым !!!! когда времячко найдете.

Evgesha писал(а):поделитесь пожалуйста блоком монитора готовым !!!!

О каком мониторе речь?

О том который перелистывать экраны проще. Олед по и 2 с шине. Маленький цветной типа.