Я не знал про такое CTRL+M, потом чуть вернул обратно Удобная штука, почему я раньше не знал?
Не хочется открывать новую тему, тем более что тоже насчет размера - размер шрифта при редактировании(например formatstr) не нашел где поменять или его нельзя менять?

Его нельзя менять

Dilma, добавь пожалуйста в редактор текста реакцию на CTRL+A

Dilma, предложение по Ctrl+A поддерживаю

Для этого мне кажется надо развивать искуственный интелект типа автосоединения точек
и автопоявление компонентов типа HUB и других.
Есть по этому поводу идея.
Например при попытке соединения выходной точки с верхней автоматическое вставка Memory.
При попытке с hubEX получить вторую выходную точку менять автоматом на HUB .
Автоформирование точек у HUB при касании его линком(как у мультика).
И т.д.


Это типа собрать процессор Pentium 4 на микросхемах 155 серии.
Круто

В душе (и не только) я согласен. Наверное, народ прикалывет создавать огромные схемы из тьмы компонентов. Но про это -- лучше молчать. ИМХО.

Почти все дельфяни этим болеют - не различают Интерфейс от Реализации
Убеждены, бедолаги, что если класс, то обязательно динамически организованная память в Heap-е.
А про то, что в CPP (к примеру) метод класса может быть inline по определению - даже и не слышали

[size=-2]------ Добавлено в 23:51

Ума-то нету
Слезливый вы наш

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

Ты представляешь себе размер этого компьютера
Galkov_у, прийдётся нанимать 20 тонный грузовик что бы он возил его ноут.

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

Теперь подумаем какие выходы из этого положения вообще есть. Их всего два:
1) Расширение существующих компонент
2) Возможность создания для пользователя собственной компонентной базы на основе простых элементов из стандартного набора

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

Я не даром все чаще ссылаюсь на достижения, сдлеанные в пакете PHP. Его концепция и вся технология реализации решает массу проблем, с которыми HiAsm раньше не справлялся и которые являлись его минусами. В том числе и эту проблему там удалось решить на ура - за счет достаточно низкоуровневой базы элементов, остающихся однако в превычной концепции hiasm там можно собрать любой более навороченный элемент по качеству не уступающим тому, что можно бы было реализовать в коде. Это значит, что там просьба добавить компоненту ChannelToIndex нижнюю точку Index могла решиться со стороны пользователя примерно так:
code_1206.txt

и эта реализация абсолютно ничем по кодам не отличалась бы от того, чтобы в данном случае мог сделать автор компонента.
Кроме того с последним коммитом была добавлена возможность межкомпонентой оптимизации, чего в пакете Delphi никогда не было и не может быть добавлено при существующей технологии сборки конечного проекта. Эта возможность позволяет компонентам распознавать при генерации кода некоторые специфические для них включения и делать за счет этого конечный код даже лучше того, что пишет программист со средним опытом и знаниями

Поэтому считайте, что впереди нас ожидает новый HiAsm 4.0, который даст пользователю действительно неограниченные возможности в развитие своих проектов как на нисшем уровне(реализация элементов в коде), так и на высшем(реализация элементов на самих же элементах) причем без потери качества и скорости работы. Кроме того такая возможность позволит со спокойной совестью избрать базовым один из свободнораспространяемых компиляторов с языка С++, что в свою очередь избавит от проблем с поддержкой двух решений под FPC и Delphi. И наконец после этого можно будет говорить о HiAsm как о законченом автономном продукте с собственным подходом к написанию приложений, способным на равных конкурировать с любым современным средством разработки

Вообщем круто.

Будем ждать!

Вот этоя понимаю -- достойный ответ. И значит, придется учить другой язык -- более перспективный.

nesco, а ты С++ знаешь?

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