» создание интерфейса (пользователя) прикладной программы

не учите дедушку кашлять...
в вмысле, дружеская шутка...
WIN32 API я знаю вполне...
с *nix хуже...
но чтобы _один_ и тот же код компилился под _две_ (как минимум платформы...)

в общем, (как я вижу теперь для себя) задача свелась к:
написать счёт+гуи для вин32 (здесь я помощи не прошу)
+
one+гуи под Линь с теми же сорсами...
вот в чём вопрос...

кстати, винтеракторы проснулись и с охуитель***ной заинтересованностью
спрашивают уже у меня (!) почему их компилированные *.dcu d7.0/d2005 не пойдут
у меня под delphi 2006...
мне смеяться или плакать?

Хорошо, а если пойти стандартным путем? То есть если взять любую книжульку по Фортрану, там утверждается: всякие гуёвины пишут на Дельфях, С++ или Visual Basic, заворачивают в DLL, а основную прогу пишут на Фортране. Или наоборот: Фортрановские расчеты убирают в DLL, а основную прогу делают чисто с гуями. Короче, можно взять какой-нибудь кроссплатформенный бейсик (например, FreeBasic) и завернуть на нем все гуи, присобачить фортрановскую DLL, и все дела. Либо насобачить на Дельфях, а под пингвина компилировать на FreePascal, он с Дельфями во многом совместим. Или на Бурляндовском же Кайликсе - 100% совместимость.

да под вин32 у меня всё так уже давно и сделано...

кстати, непоскромничаю, именно из-за меня (ну или я к этому приложил руку тоже),
начиная с версии интел 8.0 поддерживается тип "Cray pointer" -- так я передаю ФОРТРАНу
указатели на Дельфи-процедуры... переменными!, а не в списке параметров...
знатоки -- да оценят!

в общем, хАчу винтерактер...
прежде чем начинать писать _две_ версии своей программы...

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

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

дело за малым -- грамотно спроектировать программу...

Цитата:

... http://msdn.microsoft.com/library/en-us/dnwue/html/ch14e.asp - точные (в пикселах, размеры кнопок и прочих контролов для визуального проектирования)

На самом деле в этом разделе библиотеки размеры указаны в DLU (dialog units) а не пикселах.

Там же сообщается, что

Vertical DLU = 1/8 высоты установленного системного шрифта в пикселах
Hosrizontal DLU = 1/4 ширины установленного системного шрифта в пикселах

Вопрос:
Кто знает как узнать ширину и высоту выбранного системного шрифта (в моем случае Tahoma 8).
Какой символ надо взять для измерения этих величин? (Буквы "Н, Ж, Щ" сильно отличаются по ширине, собственно как и "а, б, р" по высоте)

Перерыл весь интернет, нашел много таких же вопросов, но кроме листинга кода, ничего не нашел.

Может быть кто-нибуть скажет сколько пикселов = 1 DLU при 72 dpi Tahoma 8 ?

koala
ты о gettextmetrics() говоришь?
а что за код-то? может из него всё ясно и становится...

Вот Борланд, например, в своих гуи-программах берут высоту и ширину 'Hp'

А мне кажется, что лучше делать как докоматик - составлять нумерованный список функционала на метоплатфоренных принципах _fnn_0002_ = десятичное число; а дальше по накатанной - гуи-подкомпилер - развилка под платформы. Что удастся увязать то и в пределах возможного.

NewbieCnt
это ты кому? и о чём? если по теме, то что-то не понятно...

итак, дело дошло непосредственно до разработки...

имею ещё один большой и сложный (для меня) вопрос:
на чём делать?

до сих пор обычно я ограничивался стандартной vcl (речь идёт о Дельфи), ну и немного "подмешивал" Raize (очень уж я уважаю Р.Конопку ещё со времён Дельфи 1.0) и, конечно же, родную RX.

Сейчас что-то мне захотелось сделать чуть более красивее и аккуратнее, т.к. пользоваться будут не только мои сотрудники... (сразу оговорюсь, что скины мне не нужны)

сижу и ковыряюсь с:
-Developer Express (во, блин, монстр...)
-TMS Components
-Dream
-Jasmine

т.е. хотелось бы сесть на _один_ единственный пакет и сделать всё на его основе, а то получается, что TaskPane&Sidebar лучше у mxComponent, TreeView -- у Виртуал TV и тд. но это не дело, разнородные компоненты сопрягать не хочется, да и разбираться во всех монстрах сразу -- тоже...

Да, программа представляет собой обычную научно-расчётную + графическая обвязка (TeeChart) ну и + всяческие диалоги с опциями... Но основных панелей много (штук 7-8)...


внимание вопрос!

что посоветует опытный All?

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

заранее спасибо всем откликнувшимся...

вот набросок...



full size (30 KB)


-----------------
+ сюда дубль вопроса из компонент:


есть ли такой компонент (панель, форма, ещё что), который имеет своим заголовком что-то подобное окошку самой среды студии (пришпилька + крест закрытия)?



я знаю, такое есть в ДевЕкспрессе, а в стандарте vcl?

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

+

вот кто рисует "докируемый" каптион в примере из
demos/DelphiWin32/VCLWin32/Docking/dockex.dpr
?

для желающих, только что нарыл, супер!

http://bdn.borland.com/article/33446

Кто как таб-интерфейс реализует?

Я на главную форму поместил TabControl и TJvEmbeddedFormPanel (JVC). На "дочерние" формы ложится TJvEmbeddedFormLink, с помощью которого "дочерняя" форма привязывается к главной. Дочерняя я беру в кавычки, т.к. FormStyle таких форм остается fsNormal, но отображаются они внутри главной формы. При создании дочерней формы я создаю Таб. При активации Таба присваиваю EmbeddedFormLink активируемой формы соответствующему свойству (FormLink) EmbeddedFormPanel.
Пришлось написать свои функции управления переключением Табов и следить за корректным уничтожением форм и соответсвующих табов.

От чистого mdi отказался в пользу Таб-интерфейса по той причине, что mdi делает доступным только одну форму и пользователь не знает ни кол-во созданных форм (читай, открытых окон), ни какие именно формы открыты (сравните с заголовками Табов). Кроме того, активировать Таб (а значит и форму) гораздо удобнее и быстрее, чем активировать дочернюю форму в mdi приложении.
Да и Microsoft рекомендует отказываться от построения mdi приложений. Заменять другим дизайном. Новые продукты MS построены с помощью Табов.

Что касается фреймов. Пересмотрю справку и демки.
Я строю сейчас в отдельных формах еще и потому, что так удобнее хранить логику работы отдельной формы в том же модуле, в котром форма описана.

Добавлено:
Почитал справку, посмотрел демку.
Все таки не хватает фреймам событий. Те же OnShow, OnActivate...

Некоторые мысли по интерфейсу (навеяно Пиаже):
http://www.sql.ru/forum/actualthread.aspx?bid=3&tid=101463&pg=2&hl=#2473992

afiget

Цитата:

Кто как таб-интерфейс реализует?

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

вот кто бы мне на пальцАх объяснил преимущества фреймов...
буде таковые имеются...

oan42
а кто такой Пиаже?

а кто такой Пиаже?
http://terpsy.ru/page/315.shtml
http://medbook.h11.ru/imuno/psyho1/page10.html

akaGM
Как именно ты программируешь Табы? Может специальный удобный компонент уже появился, который на основве данных об открытых окнах создает табы и позволяет прозрачно управлять этим всем чудом?

oan42
однако...
спас...

afiget
наверное, я не так плотно использую табы как ты...
я люблю Raize -- их и юзаю...

__http://www.raize.com

Да, TrzPageControl от Raize - это класс, ничего лучшего пока не видел.

Цитата:

Да, TrzPageControl от Raize - это класс

TrzPageControl = class
гы

хотя, с некотрых пор я и sidebar полюбил...
вот вверху _этой_ страницы скрин -- пример использования raize groupbar'a outlook стиля
(onOpen/onClose/onCreate вполне хватает)
таких компонентов сейчас до фигища -- модный хр-стиль task pane, например...

Цитата:

TrzPageControl от Raize - это класс, ничего лучшего пока не видел.

Сравнивал с
TabSet, DockTabSet (BDS 2006)
JvgTabControl (JVC)
cxTabControl (DevExpress)
?

или просто не пробовал другие? :)

Много других либ я пробовал, потому как долго искал хороший PageControl.
Из твоего списка - только DevExpress, так ему очень далеко до TrzPageControl.

А где живет сие чудо JvgTabControl (JVC) или имеется в виду JVCL,
так там тоже нет JvgTabControl.

Цитата:

А где живет сие чудо JvgTabControl (JVC) или имеется в виду JVCL, так там тоже нет JvgTabControl.

Да, имеется ввиду JVCL. JVCL Globus 2. Там рядом PageControl и TabControl. Очень похож по функциональности на TabControl от DevExpress.


Цитата:

Из твоего списка - только DevExpress, так ему очень далеко до TrzPageControl.

Если не сложно, что внем такого хорошего (тебе понравилось) ,чего нет в cxTabControl?

IMHO, DevExpress (годичной давности) по сравнению с Raise в разрезе PageConrol:

Минусы DevExpress:
1) Нельзя менять местами Tabs мышкой по Drag and Drop.
2) В TcxTab нет свойства, аналогичного DisabledIndex
3) Гораздо меньше свойств для изменения внешнего вида Tab.

Плюсы DevExpress:
1)Библиотека более универсальная, динамично развивается.
2) В новых версиях видов TabStyle прибавилось.

akaGM

Цитата:

вот кто бы мне на пальцАх объяснил преимущества фреймов...
буде таковые имеются...

Я активно использую фреймы. Удобства, на пальцах, следующие:
Фрейм можно рассматривать как Panel, размещая на нем контролы и прописывая для них обработчики - это понятно. Но все это в отдельном юните. Итак, логика фрейма прописывается в отдельном юните - это раз
Затем ты один этот фрейм можешь натянуть в любом количестве форм, юзая его как обычный компонент - это два
Ты можешь наследовать фрейм, как форму, это самое главное, имхо, - у меня так несколько больших продуктов сделано. Попробуй-ка TPanel понаследуй, почувствуй так сказать, разницу

afiget

Цитата:

Почитал справку, посмотрел демку.
Все таки не хватает фреймам событий. Те же OnShow, OnActivate...

Да, событий нету, это минус.
На самом деле, я просто создаю сам эти события в описании того же фрейма
procedure OnShow; virtual;
И в событии формы OnShow вызываю рукотворный обработчик фрейма
Frame1.OnShow;



Добавлено:

Цитата:

TJvEmbeddedFormPanel (JVC)

Использовать сторонние компоненты, тем более, такие глючные как JEDI - моветон. Профессиональным программерам это делать запрещено

Однако... Почему бы тогда не отмоветонить программистов,
использующим вместо TDBGrid гриды от DevExpress, EhLib, IP4000
или самоиздат на их основе?

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

С другой стороны, сила Delphi как раз в том, что профессиональные программеры
МОГУТ использовать сторонние компоненты (ПОСЛЕ ИХ ДОРАБОТКИ до нормального состояния) или могут разрабатывать свои компоненты.

Например, я уже 8 лет использую в качестве форм-контейнера
TcsFormPanel = class(TCustomPanel)
из библиотеки ClassComp.

Сразу поменял в нем несколько строк (исходник < 6 Кбайт и никаких зависимостей)
и усе путем, на фиг фреймы, кругом только формы и маленькие такие контейнеры

oan42
Ладно, флеймить не буду, скажу, что сам использую EhLib
ибо очень профессиональный пакет.
Я просто с предубеждением к JEDI отношусь - накололся там пару раз, и больше не использую
ЗЫ А пост мой был про фреймы - это рулез, что я собственно и объяснил


Цитата:

Например, я уже 8 лет использую в качестве форм-контейнера
TcsFormPanel = class(TCustomPanel)
из библиотеки ClassComp.

Предполагаю, что TcsFormPanel был реализован еще до появления фреймов, я прав ?

Скорее всего прав, в 1996 году фреймов в Delphi не замечал.

IMHO, технологии встраивания форм на основе TFrame vs TcsFormPanel (и его аналоги):

Минусы TFrame:
1) Дополнительный компонент из разряда парадигмообразующих,
хотя для достижения основной цели (контейнер формы) существует гораздо более простой способ.
2) Реализация TFrame довольно навороченная, особенно в IDE.

Плюсы TFrame:
1) Визуализация на форме-владельце.
2) Может быть контейнером не только как двоюродный брат формы, но и как некоторый часто встречающийся
набор компонентов с принадлежащей им бизнес-логикой.

vladk1973
спасибо за "распальцовку", действительно кратко, а главное -- вроде понятно...

oan42

Цитата:

TcsFormPanel из библиотеки ClassComp

что это, поделись?

Есть еще третий подход для форм-контейнеров - TacEmbeddedForm из appcontrols.

Цитата:

The acEmbeddedForm component used to insert the form and all its content to any successor of
TWinControl (i.e: Panels, GroupBoxes, Labels, pages of PageControl etc).

This is better than usual frames that comes with Delphi/BCB beginning from v5 since:
1. You can dynamically change the container of the embedded form at run-time (dynamically insert
or remove the form from any successor of TWinControl).
2. Still have all functionality of usual form (some controls can be placed only to form or its
successor).