Компоненты для Delphi-2

Форумы Новые пакетыКомпоненты для Delphi-2 ← Ctrl1 2 3 456 7 8 9...12 13 14 15 16Ctrl →

Этот топик читают: Гость

Администрация

Ответов: 15295

Рейтинг: 1519

#61: 2007-06-29 17:11:36 ЛС | профиль | цитата

Это не мысль, а прямое следствие правильно выбранного пути: в пакете Delphi classic корректность соединения линков невозможно было узнать просто физически. Поэтому и мысль такая придти не могла ни в каком виде...

карма: 27

https://hiasm.com

Ответов: 3655

Рейтинг: 69

#62: 2007-06-29 21:04:57 ЛС | профиль | цитата

Dilma писал(а):

полагаю для FTCG пакетов имеет смысл сделать возможность подцветки ошибочных линков прямо в среде после компиляции.

Это навело на мысль.
А что если сделать показ созданнго PAS файла по горячим клавишам как CtrlP

Типа сделал компонент нажал посмотрел что получилось.
Собрал схему нажал посмотрел что получилось.(и покричал на Dilma - типа плохой код

)

карма: 0

Администрация

Ответов: 15295

Рейтинг: 1519

#63: 2007-07-01 21:04:56 ЛС | профиль | цитата

Вячеслав, исходный код проекта как и в стандартном пакете можно посмотреть после нажатия Ctrl+D - он остается тогда в папке Code

карма: 27

https://hiasm.com

Ответов: 3655

Рейтинг: 69

#64: 2007-07-01 21:54:52 ЛС | профиль | цитата

Dilma писал(а):

он остается тогда в папке Code

Так я как раз про это.
В отличии от Delphi 1 просматривать код требуется гораздо чаще
поэтому и хотелось бы иметь такую оперативность.

карма: 0

Разработчик

Ответов: 26115

Рейтинг: 2126

#65: 2007-07-01 21:56:36 ЛС | профиль | цитата

Вячеслав писал(а):

В отличии от Delphi 1 просматривать код требуется гораздо чаще

Но это пока, затем, все это должно наладиться.

карма: 22

Администрация

Ответов: 15295

Рейтинг: 1519

#66: 2007-07-01 22:08:42 ЛС | профиль | цитата

nesco писал(а):

Но это пока, затем, все это должно наладиться.

именно

карма: 27

https://hiasm.com

Ответов: 3655

Рейтинг: 69

#67: 2007-07-01 22:09:12 ЛС | профиль | цитата

nesco писал(а):

Но это пока

Вряд ли
Сейчас Delphi 2
Потом С++
Потом Линукс
Потом Ещё чего нибудь.

карма: 0

Разработчик

Ответов: 26115

Рейтинг: 2126

#68: 2007-07-01 22:38:07 ЛС | профиль | цитата

Вячеслав, но отлаживается сам принцип, тб концепция кодогенератора новой серии.

карма: 22

Администрация

Ответов: 15295

Рейтинг: 1519

#69: 2007-07-01 22:45:54 ЛС | профиль | цитата

Вячеслав, в новой версии HiAsm будет доступен новый пакет: Modules - предоставляет возможность проектирования внешних модулей для HiAsm(файлы установки *.his, make файлы для проектов пакета, в перспективе: direct.inc для FTCG и прочее). Сделать такое в рамках базовой объектной модели невозможно впринципе.

карма: 27

https://hiasm.com

Ответов: 3655

Рейтинг: 69

#70: 2007-07-01 23:09:46 ЛС | профиль | цитата

Dilma писал(а):

Сделать такое в рамках базовой объектной модели невозможно впринципе.

Ну так бы сразу и сказал

Dilma писал(а):

в новой версии HiAsm будет доступен новый пакет: Modules

Уже хочу

карма: 0

Администрация

Ответов: 15295

Рейтинг: 1519

#71: 2007-07-02 00:08:20 ЛС | профиль | цитата

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

his.png

карма: 27

https://hiasm.com

файлы: 1

his.png [15.2KB] [557]

Ответов: 3655

Рейтинг: 69

#72: 2007-07-02 00:29:02 ЛС | профиль | цитата

Dilma писал(а):

Все делается с помощью Конструктора и элементов

Класс

карма: 0

Ответов: 9906

Рейтинг: 351

#73: 2007-07-02 09:28:12 ЛС | профиль | цитата

Dilma,

1) Ctrl+D - это хорошо, конечно. Но можно было бы ввести автоматическое НЕ удаление файлов, при ошибках компиляции. Или опционально-автоматически....

2) Присматриваются проблемы с областями видимости. Если мы будем заводить классы (а мне кажется, что лучше объекты, и не создавать их динамически без необходимости) отличные от TSuperClass_0, то при попытке получить имя типа win_5.CurIndex из другого мультика, оно запросто может оказаться "невидимым".
Имя типа win_5 формируется ведь CG, ему видимо и следует знать о неком "полном префиксе"

3) Да и поля private в определениях класса, как-то теряют смысл - при генерации кода "нечеловеком"

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#74: 2007-07-02 10:22:21 ЛС | профиль | цитата

вот так на вскидку думается, что ошибок с областями видимости быть не должно. Я уже т-щу Nic,у как-то говорил про то, что некоторые элементы языков ВУ сделаны исключительно ради удобства программиста и группы программистов. Поля доступа private, public и protected относятся ко второй группе. Т.е. для нас впринципе абсолютно по барабану в какой секции объявлять переменные - на размере и производительности конечного приложения этьо никак не скажется. А значит, если надо, то все можно объявлять в секции public.
На счет обращения к данным между контейнерами - еще нужно думать. Пока же вероятно имеет смысл сделать самый дубовый способ через реализацию св-ва или метода класса, возвращающего значение с данной точки - никакой прямой передачи полей.

[size=-2]------ Добавлено в 10:22

Galkov писал(а):

а мне кажется, что лучше объекты, и не создавать их динамически без необходимости

для Delphi можно и объекты. В С++ как-то нет собой разницы

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#75: 2007-07-02 10:36:10 ЛС | профиль | цитата

4) Про метод init для элементов - подумали.
А вот про метод delete - нет...
Кстати, как в KOL не стараются изничтожать дочерние контроллы, а и в нем не все таким способом изничтожается. К примеру, таймеры, потоки...
Хотя, это уже вопрос концепции, видимо

5) Про концепцию
Таки аргумент, что не все может быть "массивом" не представляется мне убедительным против именно концепции
Согласен: элементу For не следует иметь св-в динамического мультика.
Зато очень многим ведь это было бы не бессмысленно. Даже в неожиданных местах: Memory, к примеру
Эдакое разделение на "два класса" вроде не самое тупиковое место, и ничем не сложнее (вроде бы

) разделения на визуальные, и нет...
К тому же, пока не очень ясно как именно на сегодняшнюю концепцию должен реагировать редактор форм...
Dilma, изложи свои мысли на этот предмет.
Напомню: мое предложение - гибрид концепций Delphi-1 и Delphi-2

6) Чего-то мне думается, что следует заменить элемент Run на продвинутую версию элемента Application (а может и имя ему сменить на более понятное дельфянам - типа ProcessMessages).
Добавить еще один вариант формы: Applet - и именно в него перенести св-во Caption из Application
Какой-нибудь элемент типа SysMenu будет в последствии соответствующие менюхи и менять.
И что главное - будет прозрачно понятно какие
И собственная иконка - по делу.
И именно в нем (и только в нем) делать

Applet := NewApplet(_prop_Caption);[/code]
А коль скоро такой элемент не определен до определения главной формы, творить
frm2 := NewForm(nil,'Form');
Applet := frm2;
Хотя лучше бы иметь возможность везде заменить frm2 на Applet. Пока не очень понятно как и на каком уровне это лучше делать...

[size=-2]------ Добавлено в 10:36 [/size]
[quote=Dilma]вот так на вскидку думается, что ошибок с областями видимости быть не должно[/quote]
Должно
Как только мы начнем заниматься структурированием. А абсолютным инлайнингом контейнеров.
Если абсолютный инлайлинг, то у нас всегда будет только один класс (объект) и только его методы, из которых все будет видно, безусловно.

Но предположим, что рано или поздно мы напишем такой код:
type
  TSDK_0 = object
   public
    win_1:PControl;
    win_2:PControl;
    SDK_4:TSDK_3;
    SDK_5:TSDK_3;
....
  end;
Вопрос: как методы TSDK_3 (мы же должны предполагать что они там есть) увидят коды типа win_1.width :?:

карма: 9

Форумы Новые пакетыКомпоненты для Delphi-2 ← Ctrl1 2 3 456 7 8 9...12 13 14 15 16Ctrl →


Сообщение ...
Прикрепленные файлы (файлы не залиты)