Здравствуйте, Cyberax, Вы писали:

>> C>CPrettyButton — это моя кнопочка, которая умеет менять свой шрифт,
>> C>цвета, работать как push-like-button и т.п.
>> В Вилариба уже давно сменили стандартное свойство у стандартного
>> контрола,
>> а в Вилабаджо все еще пишут свои классы для кнопочек.

C>Нет, Вилабаджо уже давным-давно знают про сайт
C>http://www.codeproject.com/ и уже давно скачали кучу всяких контролов
C>(там есть и поддержка изменения шрифтов:
C>http://codeproject.com/wtl/wtlwindowfont.asp).

Вот мы и приехали к тому, откуда начали — нету для С++ нормальных библиотек для GUI.
Потому что для элемнтарных действий надо что-то откуда-то качать или
писать экраны кода.

Kh_Oleg пишет:

> C>Нет, Вилабаджо уже давным-давно знают про сайт
> C>http://www.codeproject.com/ и уже давно скачали кучу всяких контролов
> C>(там есть и поддержка изменения шрифтов:
> C>http://codeproject.com/wtl/wtlwindowfont.asp).
> Вот мы и приехали к тому, откуда начали — нету для С++ нормальных
> библиотек для GUI.
> Потому что для элемнтарных действий надо что-то откуда-то качать или
> писать экраны кода.

А какие проблемы скачать контрол?

WTL по своей сути — это barebone-система, дающая самый минимум
функциональности (и маленькие исполняемые файлы, соответственно), на
которой уже можно строить почти что угодно. И мне нафиг не нужно, чтобы
в дистрибутив WTL включались всякие красивоукрашенные кнопочки и т.п.

А вот как Дельфисты выпадают в осадок, когда нужно сделать что-то
нетривиальное и не находится нужный контрол — я прекрасно знаю.

Вот в GTK ничего качать не надо — там у виджетов можно явно назначать
шрифты.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

>> C>Нет, Вилабаджо уже давным-давно знают про сайт
>> C>http://www.codeproject.com/ и уже давно скачали кучу всяких контролов
>> C>(там есть и поддержка изменения шрифтов:
>> C>http://codeproject.com/wtl/wtlwindowfont.asp).
>> Вот мы и приехали к тому, откуда начали — нету для С++ нормальных
>> библиотек для GUI.
>> Потому что для элемнтарных действий надо что-то откуда-то качать или
>> писать экраны кода.

C>А какие проблемы скачать контрол?
А проблемы в том, что скачать контрол — это самая простая часть Марлезонского балета.
Еще надо убедиться, что он работает правильно, стабильно и надежно.
Если это не тривиальная кнопочка, то время поиска и тестирования нужного компонента
может поставить под угрозу весь проект.

А какие проблемы самому написать? — скажет мой оппонент. — Вечно эти
дельфисты (хотя причем здесь Delphi, разве я его упоминал?) ни черта писать не умеют,
а только требуют: "Дайте мне компоненту".

Вот тут упоминали, что куча продуктов (Office, Adobe family, etc.) написана на С++. Написана, но в каждом
случае разработчикам приходилось писать свой framework конкретно под свой продукт (или семейство продуктов).

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

Вывод: для С++ нет нормальной (надежной и полнофункциональной) библиотеки для GUI.

C>WTL по своей сути — это barebone-система, дающая самый минимум
C>функциональности (и маленькие исполняемые файлы, соответственно), на
C>которой уже можно строить почти что угодно. И мне нафиг не нужно, чтобы
C>в дистрибутив WTL включались всякие красивоукрашенные кнопочки и т.п.
Ассемблер предоставляет еще большие возможности, а программы на нем получаются еще меньше,
так что это отнюдь не достоинство данной библиотеки.

Kh_Oleg пишет:

>>> Вот мы и приехали к тому, откуда начали — нету для С++ нормальных
>>> библиотек для GUI.
>>> Потому что для элемнтарных действий надо что-то откуда-то качать или
>>> писать экраны кода.
> C>А какие проблемы скачать контрол?
> А проблемы в том, что скачать контрол — это самая простая часть
> Марлезонского балета.
> Еще надо убедиться, что он работает правильно, стабильно и надежно.

И это делается в большинстве случаев веьсма просто — так как такие
контролы являются просто тонкими надстройками над WinAPI.

> Если это не тривиальная кнопочка, то время поиска и тестирования
> нужного компонента
> может поставить под угрозу весь проект.

А нетривиальные _визуальные_ контролы нужны бывают очень редко.
Единственное, что вспоминается — это таблички бывают сравнительно часто
нужны. А с невизуальными библиотеками в С/С++ проблем никогда не было (в
том числе и с тщательно протестированными).

> Вот тут упоминали, что куча продуктов (Office, Adobe family, etc.)
> написана на С++. Написана, но в каждом
> случае разработчикам приходилось писать свой framework конкретно под
> свой продукт (или семейство продуктов).

Нет. Базовый MFC используется почти везде в новых продуктах. А вот в

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

Давно уже не так, если не важна портируемость (кстати, Дельфи тоже
никуда не портируется — Kylix лучше и не вспоминать).

А вот с переносимостью GUI — плохо. Прежде всего потому, что на разных
платформах разные идеологии и методы построения GUI. Тот же Word для
Маков, например, выглядит совсем не так, как его виндовый аналог.

> Вывод: для С++ нет нормальной (надежной и полнофункциональной)
> библиотеки для GUI.

Есть. MFC, Stringray, и т.п.

Вот портируемых маловато пока.

> C>WTL по своей сути — это barebone-система, дающая самый минимум
> C>функциональности (и маленькие исполняемые файлы, соответственно), на
> C>которой уже можно строить почти что угодно. И мне нафиг не нужно, чтобы
> C>в дистрибутив WTL включались всякие красивоукрашенные кнопочки и т.п.
> Ассемблер предоставляет еще большие возможности, а программы на нем
> получаются еще меньше,
> так что это отнюдь не достоинство данной библиотеки.

Ассемблер использовать сложно, в отличие от WTL.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

>> Если это не тривиальная кнопочка, то время поиска и тестирования
>> нужного компонента
>> может поставить под угрозу весь проект.

C>А нетривиальные _визуальные_ контролы нужны бывают очень редко.
C>Единственное, что вспоминается — это таблички бывают сравнительно часто
C>нужны. А с невизуальными библиотеками в С/С++ проблем никогда не было (в
C>том числе и с тщательно протестированными).

Можно ли взглянуть на следующие визуальные компоненты, написанные на С++:
1. TreeView, который не поперхнется от ста тысяч элементов и не будет
причиной даже полусекундной задержки при отображении на экране, а также
массивных вставках и удалениях. Сортировка тоже нужна.
2. ListView с аналогичными требованиями.
3. PropertyEditor.

>> Вот тут упоминали, что куча продуктов (Office, Adobe family, etc.)
>> написана на С++. Написана, но в каждом
>> случае разработчикам приходилось писать свой framework конкретно под
>> свой продукт (или семейство продуктов).

C>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
Ссылки в студию.

>> Вывод: для С++ нет нормальной (надежной и полнофункциональной)
>> библиотеки для GUI.
C>Есть. MFC, Stringray, и т.п.

Наша сказка хороша — начинай сначала. Только что подробно разобрали, почему конкретно
MFC нельзя использовать для разработки, и тут на тебе опять.
Если больше аргументов нет, то дискуссию пора прекратить.

Kh_Oleg пишет:

> C>А нетривиальные _визуальные_ контролы нужны бывают очень редко.
> C>Единственное, что вспоминается — это таблички бывают сравнительно часто
> C>нужны. А с невизуальными библиотеками в С/С++ проблем никогда не
> было (в
> C>том числе и с тщательно протестированными).
> Можно ли взглянуть на следующие визуальные компоненты, написанные на С++:
> 1. TreeView, который не поперхнется от ста тысяч элементов и не будет
> причиной даже полусекундной задержки при отображении на экране, а также
> массивных вставках и удалениях. Сортировка тоже нужна.

Начнем с того, что дерево со 100000 одновременно видимых элементов не
будет удобно использовать. Ну а так: SysTreeView в WinAPI Common
Controls и его обертки CTreeView в WTL/MFC.

> 2. ListView с аналогичными требованиями.

SysListView с обертками CListView.

> 3. PropertyEditor.

То есть?

> C>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
> Ссылки в студию.

Сайт MSа, сейчас найду...

> C>Есть. MFC, Stringray, и т.п.
> Наша сказка хороша — начинай сначала. Только что подробно разобрали,
> почему конкретно
> MFC нельзя использовать для разработки, и тут на тебе опять.

Я услышал только один аргумент: не кроссплатформенная. Ну так оно
никогда таким и не планировалось.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

>> C>А нетривиальные _визуальные_ контролы нужны бывают очень редко.
>> C>Единственное, что вспоминается — это таблички бывают сравнительно часто
>> C>нужны. А с невизуальными библиотеками в С/С++ проблем никогда не
>> было (в
>> C>том числе и с тщательно протестированными).
>> Можно ли взглянуть на следующие визуальные компоненты, написанные на С++:
>> 1. TreeView, который не поперхнется от ста тысяч элементов и не будет
>> причиной даже полусекундной задержки при отображении на экране, а также
>> массивных вставках и удалениях. Сортировка тоже нужна.

C>Начнем с того, что дерево со 100000 одновременно видимых элементов не
C>будет удобно использовать.
Я бы даже сказал, что 10^5 ты и не отобразишь на экране. Нет, одновременно
видно столько, сколько видно, скажем 100. Но вот, сотрировка, поиск, скроллинг
от первого к последнему по всем ста тысячам, быстрые вставки и удаления должны быть.

>> 3. PropertyEditor.
Неужто никогда не видел и не пользовался? В VisualStudio нажимаем F4 — вот оно и нужно.
Где взять?

>> C>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
>> Ссылки в студию.
C>Сайт MSа, сейчас найду...
Ждем-с...

Здравствуйте, Kh_Oleg, Вы писали:

K_O>Можно ли взглянуть на следующие визуальные компоненты, написанные на С++:
K_O>1. TreeView, который не поперхнется от ста тысяч элементов и не будет
K_O> причиной даже полусекундной задержки при отображении на экране, а также
K_O> массивных вставках и удалениях. Сортировка тоже нужна.
K_O>2. ListView с аналогичными требованиями.
K_O>3. PropertyEditor.

Хочешь сказать, этим требованиям удовлетворяет VCL-ный tree и list?

C>>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
K_O>Ссылки в студию.

Зачем ссылки, Spy натрави на окошко...

K_O>Наша сказка хороша — начинай сначала. Только что подробно разобрали, почему конкретно
K_O>MFC нельзя использовать для разработки

Гхм... я прослушал. Ещё раз, пожалуйста.

Здравствуйте, Amidlokos, Вы писали:

K_O>>Можно ли взглянуть на следующие визуальные компоненты, написанные на С++:
K_O>>1. TreeView, который не поперхнется от ста тысяч элементов и не будет
K_O>> причиной даже полусекундной задержки при отображении на экране, а также
K_O>> массивных вставках и удалениях. Сортировка тоже нужна.
K_O>>2. ListView с аналогичными требованиями.
K_O>>3. PropertyEditor.

A>Хочешь сказать, этим требованиям удовлетворяет VCL-ный tree и list?
Я лишь хочу обосновать пункт из самого первого поста ветки: не существует нормальной GUI библиотеки на С++.
Qt самая лучшая из всех, но и ее нормальной назвать нельзя.

Для Delphi такие компоненты существуют, но о Delphi речь не идет, когда приходится писать на С++. Вот тут и
сталкиваешься со всем списком проблем, с который и началось данное обсуждение.

C>>>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
K_O>>Ссылки в студию.

A>Зачем ссылки, Spy натрави на окошко...
И куда смотреть? На класс окна?

Kh_Oleg пишет:

> C>Начнем с того, что дерево со 100000 одновременно видимых элементов не
> C>будет удобно использовать.
> Я бы даже сказал, что 10^5 ты и не отобразишь на экране. Нет, одновременно
> видно столько, сколько видно, скажем 100. Но вот, сотрировка, поиск,
> скроллинг
> от первого к последнему по всем ста тысячам, быстрые вставки и
> удаления должны быть.

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

>>> 3. PropertyEditor.
> Неужто никогда не видел и не пользовался? В VisualStudio нажимаем F4 —
> вот оно и нужно.
> Где взять?

А, понял. Мы используем самодельный (требования специфичные) на основе
list view.

>>> C>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
>>> Ссылки в студию.
> C>Сайт MSа, сейчас найду...
> Ждем-с...

Ищу...

--
С уважением,
Alex Besogonov (alexy@izh.com)

Kh_Oleg пишет:

> A>Хочешь сказать, этим требованиям удовлетворяет VCL-ный tree и list?
> Я лишь хочу обосновать пункт из самого первого поста ветки: не
> существует нормальной GUI библиотеки на С++.
> Qt самая лучшая из всех, но и ее нормальной назвать нельзя.

Эту ветку следует переформулировать так: не существует нормальной
GUI-библиотеки (вообще).

> Для Delphi такие компоненты существуют, но о Delphi речь не идет,
> когда приходится писать на С++. Вот тут и
> сталкиваешься со всем списком проблем, с который и началось данное
> обсуждение.

Для Дельфи нет вопроса о портируемости (так как нет портируемости). А
подобных непортабельных решений для MFC — тонны.

> A>Зачем ссылки, Spy натрави на окошко...
> И куда смотреть? На класс окна?

Да. Скорее всего будет "SysTreeView".

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

>> A>Зачем ссылки, Spy натрави на окошко...
C>Да. Скорее всего будет "SysTreeView".
SysTreeView32. Только это говорит о том, что используется стандартный компонент операционной системы,
но никак не MFC.

А ссылки ждем-с...

Здравствуйте, Cyberax, Вы писали:

>> C>Начнем с того, что дерево со 100000 одновременно видимых элементов не
>> C>будет удобно использовать.
>> Я бы даже сказал, что 10^5 ты и не отобразишь на экране. Нет, одновременно
>> видно столько, сколько видно, скажем 100. Но вот, сотрировка, поиск,
>> скроллинг
>> от первого к последнему по всем ста тысячам, быстрые вставки и
>> удаления должны быть.

C>Сортировку, поиск и скроллинг должно делать само приложение — дерево
C>просто отображает результаты. Вставка и удаление в стандартном списке
C>работают достаточно быстро.

Ути-пути, само приложение!
Когда-то и автомобиль считался роскошью, а теперь это — средство передвижения.

>>>> 3. PropertyEditor.
C>А, понял. Мы используем самодельный (требования специфичные) на основе
C>list view.
Требования у всех специфичные. Только для Delphi такой компонент существует, а для С++ — до сих пор нет.

>> Ждем-с...
C>Ищу...

Kh_Oleg пишет:

>>> A>Зачем ссылки, Spy натрави на окошко...
> C>Да. Скорее всего будет "SysTreeView".
> SysTreeView32. Только это говорит о том, что используется стандартный
> компонент операционной системы,
> но никак не MFC.

Кхе-кхе.... MFCшный CTreeView является просто тонкой оберткой для
SysTreeView32.

> А ссылки ждем-с...

Найти не могу, куда она запропастилась, блин???

--
С уважением,
Alex Besogonov (alexy@izh.com)

Kh_Oleg пишет:

> C>Сортировку, поиск и скроллинг должно делать само приложение — дерево
> C>просто отображает результаты. Вставка и удаление в стандартном списке
> C>работают достаточно быстро.
> Ути-пути, само приложение!

Да. Само приложение, хотя 10^5 записей и дерево сможет отсортировать.

>>>>> 3. PropertyEditor.
> C>А, понял. Мы используем самодельный (требования специфичные) на основе
> C>list view.
> Требования у всех специфичные. Только для Delphi такой компонент
> существует, а для С++ — до сих пор нет.

И для С++ существует, причем не в одном варианте. Мы же не с 0 свой
контрол писали.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Kh_Oleg, Вы писали:

K_O>Ути-пути, само приложение!
K_O>Когда-то и автомобиль считался роскошью, а теперь это — средство передвижения.

Ну, если для нас, дурачков, всё должен делать большой и умный дядя, то Вы, уважаемый, ошиблись форумом.

Кроме того — ну, а где (повторю это любимое слово) ссылка-то на этот дельфовский суперкомпонент? Где пример программы с десятком тысяч node-ов?

K_O>Требования у всех специфичные. Только для Delphi такой компонент существует, а для С++ — до сих пор нет.

Дружно падаем дельфе в ноги. Попутно замечая, что забыли порыться на codeproject-е...

здесь (нужно ещё и текст прочитать, там пара ссылок),
здесь,
здесь, в конце концов...

Здравствуйте, Kh_Oleg, Вы писали:

K_O>SysTreeView32. Только это говорит о том, что используется стандартный компонент операционной системы,
K_O>но никак не MFC.

Однако же и совсем никак не TTreeView. Дельфийский класс так и называется — TTreeView и производные... MFC ищется ещё и просмотром зависимостей/сообщений, а также поиском классов AfxNNN.

Здравствуйте, Aibyss, Вы писали:

A>Пара вариантов при условии, что округление ответа ближе к нулю:

A>С условным оператором:

A>

A>int kaka (int a, int b){
A>   if ((a>0 && b>0) || (a<0 && b<0))
A>        return (a-b)/2+b;
A>    else {
A>        return (a+b)/2;
A>    }
A>}
A>

Абсолютно согласен — этим программистам далеко до математиков и перпендикулярно физикам!
Из-за такой ерунды они такую <b>kakashka</b> в <b>МИД</b>

Автор: Кодт
Дата: 18.02.05

превратили!!!

int ERUNDA (int a, int b){
  try
  {
    return (a+b)/2;
  }
  catch(overflow_error& ex)
  {
    return (a-b)/2+b;
  }
}

Пырдон, <b>kakashka</b>

Автор: screw_cms
Дата: 18.02.05

потерялась

Здравствуйте, Kh_Oleg, Вы писали:

K_O>Можно ли взглянуть на следующие визуальные компоненты, написанные на С++:
K_O>1. TreeView, который не поперхнется от ста тысяч элементов и не будет
K_O> причиной даже полусекундной задержки при отображении на экране, а также
K_O> массивных вставках и удалениях. Сортировка тоже нужна.

Дельфист... RTFM Win32 Common Controls API!

K_O>2. ListView с аналогичными требованиями.

см. п.п. 1.

K_O>3. PropertyEditor.

А в чем, собственно, проблема? Нет ActiveX который можно настроить в Design Time? Если очень надо — можно найти — не проблема — делал. Если не очень надо, но хотелось бы — можно сделать — делал. И первый и второй случаи — коммерческие разработки — в практическом применении уже "некоторое время"...

Empedded? Было дело: коммерческие разработки — GUI в том числе — межплатформеннопереносимые тоже — не всегда C++ — частично взаимодействие со старым и не очень кодом на C, а также на "чем-то третьем"...

>>> Вот тут упоминали, что куча продуктов (Office, Adobe family, etc.)
>>> написана на С++. Написана, но в каждом
>>> случае разработчикам приходилось писать свой framework конкретно под
>>> свой продукт (или семейство продуктов).

C>>Нет. Базовый MFC используется почти везде в новых продуктах. А вот в
K_O>Ссылки в студию.

>>> Вывод: для С++ нет нормальной (надежной и полнофункциональной)
>>> библиотеки для GUI.
C>>Есть. MFC, Stringray, и т.п.

Вы имеете в виду платформу Win32 или вообще некую абстрактную "нормальную (надежную и полнофункциональную) библиотеку для GUI"?

K_O>Наша сказка хороша — начинай сначала. Только что подробно разобрали, почему конкретно
K_O>MFC нельзя использовать для разработки, и тут на тебе опять.

Так ведь никто и не заставляет... Коммерческие интересы и бизнес не в счет...

K_O>Если больше аргументов нет, то дискуссию пора прекратить.

Да ее и начинать смысла не имело, однако для этого-то как раз и создан этот раздел форумов, чтобы можно было написать с извращенным удовольствием: дельфисты! (к)