Валерий, это глупость. Легче скачать старую версию.

1. Не всегда будут доступны старые версии.
2. В новых версиях возможно будет меняться интерфейс и для новичков.
Хотя оно и понятно, что этому не бывать У разработчиков сил еле хватает для дальнейшего развития, а поддерживать старые версии ....

Вячеслав, глядя на последний ответ я окончательно потерял надежду оставить патекику в стороне и начать обсуждать конкретные вопросы по конкретной теме. Если у вас действительно имеется желание разобраться(на что я надеюсь) с этим вопросом заходите во встроенный чат HiAsm(жду сегодня-завтра с 21.00 до 01.00) - форум(судя по всему) ни к чему кроме флейма не располагает. Готов задать еще раз теже вопросы, на которые ответ тут так и не был дан. Дальнейшее обсуждение в том же русле в этой теме предлагаю закрыть.


Валерий, для этого надо всего лишь взять любую версию стандартного пакета(от третьего поколения среды) и поубирать от туда все, что вам кажется сложным для новичков(80-120 элементов хватит вполне). И соответственно все оставшееся проверить на работу под FPC. Вот и получили набор юного пионера для тех, кто не желает заморачиваться. Поддержка проекта при этом будет заключаться в переносе пакета под новые среды. У всех, кто так печется о новичках, которым приходится непомерно много знать для работы с новыми средами будет реальный шанс доказать нам(и себе), что они способны подкрепить свои слова делом.

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

очень давно предлагал - если метод элемента не используется в схеме - не компилировать его.. Я как железячник привык ставить новинку на эстакаду и рассматривать её в разных позах целиковую, а не как сборная мебель - лежит куча разных частей, нужно сначала заизучить каждую в отдельности, а потом начинать думать - какими же сторонами их свинтить, чтобы получился диван (а не АК).. Про инструкцию не упоминаю по известной причине
Очень бы хотелось попробовать "разборный" компонент - вот он здоровенный, счёлкнул, и вместо него уже просто кучка маленьких запчастей.. Не нужен туалет на самолёте - ну и не будем тогда его монтировать - зачем он камикадзе (к примеру)



Менеджеры хороши, когда их "не много"



мде, сопсна тоже закралось такое ощущение. Визуальность только нас спасёт

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

В MMB вобще нет визуализации как такавой, однако поклонников этого конструктора меньше не становится. (сам когда то им занимался).

Маленький вопрс, А в каких случаех необходимо хинтменеджеры больше 2-х например?? Можно реальный пример из жизни!!! Именно жизненно необходимы....а не рюшечки аля для каждой записи по подсказки - радуга!!

это делает не HiAsm, а компилятор целевого кода


наверно Андрей., говорил про менеджеры вообще. Количество их использования в схеме зависит от задач, а не от того хорошо это или плохо.


у кого закрадываются ощущения прошу еще раз пересмотреть видео урок http://hiasm.1gb.ru/forum.html?q=3&t=56, который был сделан около 3х лет назад и рассказать нам, чего сегодня делается не так, как там продемонстрированно

Ты далеко не новичок в HiAsm.

Закрыто.

Окей.
Вчера так и не смог попасть на форум.

Теперь посуществу.
Менеджеры это новое понятие в Hiasm коих доселе небыло.
К тому же это глобальный объект коих доселе тоже небыло.

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

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

вот это уже похоже на объективную оценку...


GlobalVar точно такой же глобальный объект. Даже гораздо в большей степени


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

Он не влияет на функциональность других компонентов.
Впрочем словосочетание глобальный объект было примененено лишь потому что не
нашёл другого.

В моём понятии менеджер это компонент который может обладать дополнительной функциональностью
(изменять функциональность других компонентов.)
И изменённый внешний вид как раз и будет об этом говорить
(внимание, я непростой ,я глобальный)

Dilma, в первую очередь, мне кажется, надо поле Name закрасить по типу полей менеджеров, можно другим цветом. Это основное поле, которое идентифицирует самого менеджера в среде. На фоне всех серых полей оно обязательно должно выделяться

не могу согласится. Под это определение ну никак не подходит HintManager. Все Data менеджеры из пакета WEB тоже на функционал своих клиентов не влияют никак(они всего лишь предоставляют данные и не более). Поэтому давать точное опеределение я бы пока не стал.

Мне даже думается не сколько дополнительной, сколько особой - отличающейся. Ибо их влияние, не проследить привыкшему к "проводам" юзеру. А раз уж само понятие манагера задумано для борьбы с захламлённостью схемы "проводами", то и функционал его далжён быть распознаваем не линками - а внешним видом (единственный вариант, который я вижу)
несмотря на то, что



между прочим, в своё время была мысль предложить выделить её глобальность, - неискушённому хиасмисту это точно бы помогло, но как-то съехалось на тормозах..

точно, например инвертировать с фоном..