Вверх ↑
Ответов: 1429
Рейтинг: 50
#1: 2010-09-25 09:21:17 ЛС | профиль | цитата
Assasin, искренне, поздравляю, молодец! (здорово!, что ты прикрутил чтение строковых)

Хочу отметить. Этот компонент не решает проблем управления потоками, получился стандартный, хотя и весьма, "продвинутый" - if_Else.
Преимущества ты перечислил, но это только 30% функционала элемента о котором я писал, и от каскадов мы пока не избавились:

Очень часто встречается задача выбора из массива по условию, и управления потоками по условию:

Где:
if x1 = 'Login' then 0, x2 = 'Assasin' then 1, x3 = 4567 then 2 else error

(то-есть на точку True должны выходить индексы верхних точек)
Но верхняя запись громоздкая, и в максе она заменяется на подобие Case:

case 'Login' 'Assasin' 4567

В результате все сразу заталкивается в элемент в потоке, и на выходе on_True возникают индексы совпадений.
Если затолкали слово Login то выскочит нолик, если Assasin выскочит еденичка. Иначе - точка on_false.
А за элементом либо массив, либо IndexToChannel.

(это для HiAsm, в максе пошли дальше, обьеденив этот case с элементом IndexToChannel, и получили "многоэтажный case" с простым синтаксисом)

------------ Дoбавленo в 09.21:
Еще просто, нейтральная, информация:
есть разница устройства самих интерфейсов. Этот элемент у макса имеет сложный функционал, и при этом не теряет ресурсов, еще вот почему:

Палитра элементов там есть только для визуальных компонентов, а нужный логический элемент, подгружается в зависимости от того, что юзер вписал в начале строки. Если он пишет "if.." то подгружается элемент который сделал Assasin, если юзер пишет "case...", то подгружается case,
или если пишет "+" то загружается простой "Math" (и меняется его внешний вид). Это им экономит место на палитре, и ресурсы, под конкретные задачи.


карма: 0

0