freepascal.ru

В Turbo Vision благополучно не въехал в своё время, не очень надо было. Сейчас упёрся.

Суть вопроса: есть типичная наверное задача. Некий физический объект, например вектор
x,y,z,length:real;
процедуры save, load, calclength. Нарисовать картинку, распечатать.
MDI не надо. Пока. Вообще надо начать, дальше оно немного разрастётся.

Сам объект видимо нужно организовывать классом.
Вопросы - где корректно его располагать, в каком файле? В лазарусе формы лежат в отдельных модулях.
Не совсем понял, чем программа отличается от приложения, кроме того, что в одном случае начальный файл - собственно програма, а в другом - модуль с формой. Сделал вторую форму - как из неё добираться до данных?

Turbo Vision будет более надежна и более гибка, если Вы будете следовать двум правилам: сохраняйте объекты как можно более
автономными и сохраняйте группы (такие как окна) как можно более свободными от функциональной нагрузки.
... это про что вообще? Чую, что здесь тоже актуально.

я один ничего не понял?

Прочитав название, решил уже, что зародилась еще одна псевдополитическая флудотема.

serg_iv писал(а):я один ничего не понял?

Нас уже двое.

airnbrew
Вы о чём? Реально о Turbo Vision, абсолютно мёртвом уже более десятка лет, работающем на платформе, библиотеки которой неработоспособны на большинстве современных процессоров? Или о FreeVision, брошенном разработчиками за полной бесперспективностью и глючащем на не-ASCII кодировках?

airnbrew писал(а):например вектор
x,y,z,length:real;

Маловато будет.
Вы не полностью определили вектор, как объект, если на то пошло. У вас этими параметрами можно сферу описать, но не вектор.
И забудьте уже про тип real. Это (...) фактически исчезло из реальных программ вместе с TurboPascal V4 и компьютерами без сопроцессора. Помните такие i386-sx, i486SLC?

Добавлено спустя 40 секунд:
Да, и что вы хотели сказать то?

И забудьте уже про тип real.

Непрограммисту простительно.
А что нужно использовать вместо real?

Frolik писал(а):А что нужно использовать вместо real?

В зависимости от того, сколько в эту кошёлку должно влезать: или single, или double. Если уж совсем, то extended.
А вообще, real - это либо аналог single, либо double. По крайней мере у меня размер real показывает 8 байт (на 32-ух разрядной винде).

мне кажется, что Turbo Vision тут ни при чём

airnbrew,создайте юнит, куда и спрячьте весь функционал в виде класса или набора функций. В unit1(если не переименовывали ничего) создайте объект/ты нужного типа. Остальную работу стоит делать в обработчиках onChange и onClick и подобных.

airnbrew писал(а):Не совсем понял, чем программа отличается от приложения, кроме того, что в одном случае начальный файл - собственно програма, а в другом - модуль с формой.

Имхо ничем критичным не отличается.

airnbrew писал(а):Сделал вторую форму - как из неё добираться до данных?

до каких? Если находящихся в другом модуле, то добавляете модуль в uses раздел а к данным обращаетесь примерно так...

Код: Выделить всё

procedure TMainForm.MenuAbouteClick(Sender: TObject);
begin
  FormAboute.Show;
end;   

Типы и константы, насколько я помню, становятся доступными сразу.

hinst писал(а):мне кажется, что Turbo Vision тут ни при чём

Конечно, ни при чем. Просто человек захлебнулся в объеме. Сам был в таком положении.

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

Остальную работу стоит делать в обработчиках onChange и onClick и подобных.

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

Frolik, это уже детали.

Сперва "блондинка", теперь это Приколы продолжаются ...
ПС: А на FreeVision зря наехали. Например на нем можно писАть консольные (а поэтому работающие через SSH/Telnet) интерактивные проги вроде C-ых NCURCES-ких, но мощнее и функциональнее.

Лекс Айрин писал(а):airnbrew,создайте юнит, куда и спрячьте весь функционал в виде класса или набора функций.

Подозреваю, что для airnbrew это слова из какого-то заклинания.

sign, и ведь будет тогда в чем-то прав.

А если серьезно, то не думаю, что все так тяжко.

airnbrew писал(а):Turbo Vision будет более надежна и более гибка, если Вы будете следовать двум правилам: сохраняйте объекты как можно более
автономными и сохраняйте группы (такие как окна) как можно более свободными от функциональной нагрузки.

Чел книжку по Turbo Vision процитировал, а вы на него набросились. Читающий книги человек достоин уважения, а такие книги -- вдвойне. Сам по ней в свое время учился, она оказала на меня сильное влияние.

Последняя фраза из цитаты по-современному звучит как "отделяйте логику от интерфейса", -- это азы проектирования. Приложение -- это и есть программа. Про размещение классов (объектов в Turbo Vision) в своих модулях вроде говорилось в той книжке.

Vapaamies писал(а):Чел книжку по Turbo Vision процитировал, а вы на него набросились.

Чел сказал, что "в арифмометр, тьфу в Turbo Vision благополучно не въехал в своё время, не очень надо было. Сейчас упёрся."
Зачем сейчас упираться в арифм.. тьфу ещё раз, в Turbo Vision?