» Компоненты и утилиты для Delphi/BCB/FreePascal/Lazarus

Цитата:

Нужен нативный, системный вид, а не что-то

Ох, нужен! Ох, не говори... Ну почему никто не напишет хорошую библиотеку базовых компонентов БЕЗ СКИНОВ?

Ludens
Посмотрел демо Raize Components, увидел обычный тулбар +градиенты и отскиненное под офис меню...

У меня переодически возникает желание ограничится TToolbar/TCoolbar, как в MSIE. Но никогда не получалось внедрить меню в TCoolband, чтоб оно работало, а не глючило. Всегда приходилось откатываться на производные Toolbar2000

Странно, но эталон реализации тулбаров с меню я вижу в Mozilla Firefox. У них получилось максимально похоже, даже лучше чем у билли в MSIE c кривыми нативными OwnerDraw меню. Жалко, что не на Delphi написано

Цитата:

увидел обычный тулбар

Ну а ты ожидал увидеть что, НЕобычный? Мне-то вот, наоборот, кажется, что чем вид обычнее — привычнее, классичнее, стандартнее, универсальнее — тем оно правильнее.

Ludens
Я имел в виду, что обычный уже есть в виде TToolbar

0D0A
Есть-то он есть. Но — плохой. По сравнению с тем же Toolbar2000, он как Notepad по сравнению с Word. Собственно, в этом и заключается парадигма производителя расширяемых инструментов: его мощь должны создавать сторонние производители плагинов/компонентов. Поэтому штатные компоненты от производителя среды — такие, как TToolbar, TMainMenu, TButton, TEdit и т. д. — просто обязаны НЕ быть полноценными и годиться только для демонстрации возможностей Delphi.

Вы видели?! SpTBXLib обновился! Да! XE2 и 64.

Ludens

Цитата:

штатные компоненты от производителя среды — такие, как TToolbar, TMainMenu, TButton, TEdit и т. д. — просто обязаны НЕ быть полноценными и годиться только для демонстрации возможностей Delphi.

Ludens
Блин, я уж думал сдохло наконец.
Minor bug fixes

Цитата:

Minor bug fixes

исправлена, в частности, ошибка прорисовки TabSet при DoubleBuffered

dzh2000

Цитата:

Отпусти меня чудо-трава

Да не так далеко это от истины (имхо). Как минимум в первые годы жизни среды её разработчик заинтересован развить экосистему вокруг себя, а не просто включить всё возможное в саму среду, тем самим убив сотни небольших партнеров. Со временем ситуация несколько меняется, ибо и среда обязана расти. Но и тогда делается комромис на компромисе, чтобы не разозлить ключевых партнеров.

murkovich
Я не сомневаюсь, что разработчик Delphi не в силах охватить всю область применения своего продукта, и кое-что приходится либо дописывать самому, либо использовать со стороны. Но считать TEdit, TButton - неполноценными можно только после употребления какой-нибудь чудо-травы

dzh2000

Цитата:

Но считать TEdit, TButton - неполноценными можно только после употребления какой-нибудь чудо-травы

Ладно, тогда нету спора. Я думал больше о таких компонентах как всякие гриды и подобные.

Вышел CnWizards 0.9.9.627 с симпатичнейшей новой фичей разделителя описаний процедур

Ludens
Поставил, а где это увидеть можно? это новый мастер или что?

druff
Нет, это новая опция в настройках:
Main Menu / CnPack / IDE Enhancement Settings / Source Highlight Enhancements / Enable Separate Lines between Functions

Цитата:

Вышел CnWizards 0.9.9.627

Так ещё не вышел, а Unstable. А новая фича - да, интересная

Кто там спрашивал про Toolbar 2000 и либу SpTBX там версии для XE2 и вроде даже x64

http://www.armin-pfaeffle.de/blog/2011/11/toolbar2000-and-sptbx-for-delphi-xe2/#comment-1073
https://skydrive.live.com/?cid=83A7119830FC7582&id=83A7119830FC7582%21158&sc=documents

KAndrew13
боян
Эти моды от Armin (без 64) и еще кого-то (с поддержкой 64) появились за пару месяцев до того, как автор SpTBXLib сам выкатил новую версию своей гениальной библиотеки. Теперь в SpTBXLib есть «родная» полная поддержка XE2.

Цитата:

Ludens
боян
Эти моды от Armin (без 64) и еще кого-то (с поддержкой 64) появились за пару месяцев до того, как автор SpTBXLib сам выкатил новую версию своей гениальной библиотеки. Теперь в SpTBXLib есть «родная» полная поддержка XE2.

Понятно, буду знать.

Цитата:

Но считать TEdit, TButton - неполноценными можно только после употребления какой-нибудь чудо-травы

+1, особенно учитывая что это всего лишь обертки над родными окнами управления windows (EDIT и BUTTON соответственно).

в GR32_Text баг

Код: function StripCRs(const widetext: widestring): widestring;
var
i: integer;
begin
result := widetext;
i := pos(#13, widetext);
while i <> 0 do
begin
delete(result,i,1);
// i := pos(#13, widetext); // цикл уходит в небо
i := pos(#13, result); // ... с миром всё в порядке
end;
end;

редактор тем для Delphi IDE (Version 7-XE2)
приятная темная тема

JEDI VCL под XE4 можно как то использовать или ждать версию выше 3.47?

А между прочим, еще 15 апреля обновился SpTBXLib до 2.4.8

некогда искал либу для межпроцессного взаимодействия и открыл для себя Cromis-IPC
http://www.cromis.net/blog/downloads/cromis-ipc/

Цитата:

Fast inter process communication channel
Packet oriented messaging.
Hides technical implementation from user
Client/Server approach. Multiple clients, thread safe…
Multithreaded server using thread pool
Data packets are versatile data carriers
Only 0.1 ms per average message (client -> server -> client)

автор периодически обновляет либу.

utmost80
тоже видел эту библиотеку, но пока не пользовал.
Есть опыт использования? негативные моменты какие-то?

XPerformer
в комплекте имеются примеры использования, а сама либа не требует установки.
багов и утечек не замечал, но я и не передаю между процессами много объектов,
работает действительно шустро.

Вопрос к пользователям SpTBXLib. Нормально ли в одном и том же проекте использовать как компоненты SpTBX, так и их стандартные аналоги (TSpTBXLabel вместе с TLabel, TSpTBXCheckBox вместе с TCheckBox и т. д.)?
Оптимально ли я поступаю, когда употребляю компоненты SpTBX только там, где требуются их особые возможности (например, OnDrawCaption), а во всех остальных случаях юзаю штатные? Или более рационально (с точки зрения размера исполняемого файла, например), если уж где-то в проекте применяешь SpTBX, то применять его повсюду?

Ludens
Я не пользователь SpTBXLib, но если вставить в твой вопрос вместо SpTBXLib, ну например, EhLib, то вопрос в принципе не изменится. Так что выскажу свое мнение.
Оптимальность у каждого своя. В размере - для одних увеличение на 300 Кб много для других и 10 Мб не проблема. В стиле - для одних стильно и правильно все визуальные компоненты выдержать в едином виде и едином поведении, для других главное функциональность и нет проблем что в ряде случаев используются одни гриды со специфичными функциями, а в других другие, а внешний вид это так - понты.
Я лично придерживаюсь мнения, что если есть возможность использовать одного стиля компоненты и это не в ущерб функционалу программы, то так и нужно делать. Потому, что пользователю так привычней и удобней. Если критичным становится размер или функционала используемых одно стильных компонентов не хватает тогда уже надо что то менять. Если ставка на размер и быстродействие, то API вам в руки.

Добавлено:
И, да, простите за оффтоп

Ludens
С точки зрения размера экзешника нет никакой разницы, один раз используется компонента или 100. Разве что она в dfm много пишет. Так что в вашем случае остается только вопрос стиля.