Ну и что хоть планируется-то?

[melky]

capzap ессно это записано в классе программы. Результирующие строки из xml я привел выше, два варианта и оба рабочих для программы.
И вот с json подобные фокусы не проходят, по крайней мере я не нашел решения, а очень бы хотелось иметь подобное решение в активе при работе с json. А то приходится описывать кучу классов для сериализации, чтобы оно не отваливалось. з.ы. мало того, весь этот мусор еще гуляет по сети, когда опрашиваешь облако Овен, ну нафига передавать тот же false или 0 или пустую строку с именем переменной?

Век быстрого интернета и объемные диски расслабляют людей до невозможности

[melky]

capzap не, просто облако можно прочитать одним запросом меньше мусора, меньше период между запросами
И ну не забывайте, есть же еще и мобильный интернет, а там как бы другие скорости.

[capzap]

capzap не, просто облако можно прочитать одним запросом меньше мусора, меньше период между запросами
И ну не забывайте, есть же еще и мобильный интернет, а там как бы другие скорости.

Nuff said, ну как по api не в состоянии документацию изучить, так и по теме новой среды и других, только поверхностное мнение будет, для роли хейтера пойдет

[Dimensy]

Искренне желаю успехов, и, очень надеюсь, что новая среда не получится такой "деревянной" и баганутой как Лоджик и, при этом, действительно будет иметь низкий порог вхождения

[melky]

Поверхностное мнение пользователей всегда важно для развития продукта. Пользователи часто замечают то, что не в силах заметить программист. (Правда ему потом работы больше )
Ну как примитивный пример, зачем три раза клацать мышью, когда можно сделать за один щелчок другой кнопкой? Утрировано конечно.

По этому мое имхо, даже прототипы по надо выкладывать в тесты раньше, возможно некоторые вещи можно изменить на ранних этапах, когда ПО не закостенело.

[Dimensy]

Поверхностное мнение пользователей всегда важно для развития продукта.

Всем рулят, к сожалению, менеджеры. Сколько времени прошло, прежде чем в Лоджике убрали для новой линейки ПР автоматическую энергонезависимость у экранных переменных (и то с багом)

[melky]

Dimensy, я примерно о том же. Сперва напишут "не спрося", а потом добавляют в список доделок, переделок и растягивают во времени. Вместо того, чтобы сделать сразу, как больше удобнее пользователям. Да, сколько людей, столько и мнений, бесспорно, но когда эти мнения есть сразу, можно идти по лучшему пути, ну или по пути, за который "проголосовало" большинство.

C# хороший язык, в Framework-e масса готового, чем и нравится. Но типизация языка иногда просто убивает. Хочешь сделать что-то более гибкое, но тебе тут же бьют по рукам, так низя и начинаешь искать пути обхода.

[melky]

з.ы. проблема не в менеджерах, а в программистах, эти "редиски" пишут по ТЗ, при этом часто далеки от асутп, программировании ПЛК и т.д.

Как кто-то написал, их надо заставлять запускать объекты, на ими же написанном ПО

[IVM]

Сколько времени прошло, прежде чем в Лоджике убрали для новой линейки ПР автоматическую энергонезависимость у экранных переменных (и то с багом)

А что плохого в автоматической энергонезависимости у экранных переменных ?

[Dimensy]

А что плохого в автоматической энергонезависимости у экранных переменных ?

а) в общем списке переменных никак не выделяется, что она энергонезависимая
б) могут быть случаи, когда не требуется хранить параметр в энергонезависимой памяти (т.е., при перезагрузке переменная должна сброситься в ноль)
в) у автоматических энергонезависимых переменных нельзя выставить значение по умолчанию