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

C>Покажите мне, где в WinForms есть MVC.

А чем тебе в качестве модели IList или IBindingList не катит?

C>JavaDoc — это документация именно _к_ _исходникам_. То есть просто
C>документируются классы и методы — так же как и reference'ы в MSDN'е.

Только толку с нее...

C>Ну и как он будет оповещать спиок об изменениях данных? Ну а для дерева
C>вообще ничего подходящего нет.

IBindingList.ListChanged event. C деревом сложнее.

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

C>Я помню, что уже через месяц (после того, как набил шишки в нужных
C>местах) писал на Свинге быстрее, чем в редакторе. Причем было это в 2002
C>году.

Согласен. На редакторах формочек для свингов много не напишешь. Проще ручками. Еще проще — в нормальном редакторе.

C>Но! В Яве у layout'ов стандартный интерфейс, поэтому тот же JGoodies без
C>проблем может интеоперировать хоть с FlowLayout'ом из JDK1.0.1

Т.к. интероперировать не с чем, то и проблемы таковой нет.

olegkr пишет:

> C>Покажите мне, где в WinForms есть MVC.
> А чем тебе в качестве модели IList или IBindingList не катит?

Не катит, так как нормально я их переопределить не могу.

> C>JavaDoc — это документация именно _к_ _исходникам_. То есть просто
> C>документируются классы и методы — так же как и reference'ы в MSDN'е.
> Только толку с нее...

JavaDoc — это _просто_ комментарий к исходникам. Ни больше, ни меньше.

Подробная документация в JavaDoc'е не бывает (обычно), а скачивается
(вариант: браузится) отдельно.

> C>Ну и как он будет оповещать спиок об изменениях данных? Ну а для дерева
> C>вообще ничего подходящего нет.
> IBindingList.ListChanged event. C деревом сложнее.

Тогда IList уже не получится использовать, а IBindingList — достаточно
сложный и громоздкий для реализации.

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

Кодт пишет:

> C>Еще очень забавный опыт: создать в одном потоке дочернее окно с
> C>родителем в другом потоке.
> Вот только что опыт ставил. Результат — мрачный, но (через
> пень-колоду) работает.

Угу, причем ломается в самых неожиданных местах (типа SetFocus).

Я как-то пытался довести такой подход до ума — в итоге наплевал, и стал
делать GUI полностью однопоточным.

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

olegkr пишет:

> C>Я помню, что уже через месяц (после того, как набил шишки в нужных
> C>местах) писал на Свинге быстрее, чем в редакторе. Причем было это в
> 2002
> C>году.
> Согласен. На редакторах формочек для свингов много не напишешь. Проще
> ручками. Еще проще — в нормальном редакторе.

Я с VB тогда сравнивал

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

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

DB>>Я уже молчу, что иногда он (Qt) жрет процессорное время, зацикливаясь на посылках-обработках сообщений, что он вообще НЕ excetion-safe (разработчики называют это "not using exceptions" и вообще не защищают выделение ресурсов, поэтому любой виртуальный метод или обработчик сигнала должен иметь всеобъемлющий try {} catch (...) {}), что он не позволяет создавать многопоточный GUI (для отмазки предоставляя какой-то один отстойный объект синхрониации с однтим циклом обработки сообщений на все потоки!)... И т.д. и т.п.

G>Хотел бы я увидеть хотя бы одну потокобезопасную, безопасную относительно исключений библиотеку GUI.
G>И потом — методы в Qt, из которых нельзя выкидывать исключения, объявлены как throw(), т ч разработчики честно предупреждают,
G>чего они от тебя НЕ ждут (ведь ты же не имеешь привычки кидать исключения из деструктора?)
G>И вообще, многопоточность — это отдельная песня. С каждой библиотекой можно работать в многопоточной среде, просто надо соблюдать
G>ряд правил для этого. STL вон тоже не многопоточная если на то пошло...

Речь идет о моногопоточном, exception-safe GUI. Мне это позарез нужно. Таких библиотек (промышленных) только две: .NET framework и VCL (там все хуже, но все равно есть).

DB>>Версия 4 вроде бы обещает быть получше, но с исключениями и потоками она до сих пор не дружит (хотя уже есть beta).
G>Qt работает на слишком многих платформах с различными по отцтойности компиляторами — отсюда изначальная политика минимализма c++ кода.

G>P.S.: И вообще, у меня сложилось впечатление, что для тебя не обсуждение главное, а посрать в камментах побольше....

Я ставлю проблемы.

d Bratik пишет:

> G>чего они от тебя НЕ ждут (ведь ты же не имеешь привычки кидать
> исключения из деструктора?)
> G>И вообще, многопоточность — это отдельная песня. С каждой
> библиотекой можно работать в многопоточной среде, просто надо соблюдать
> G>ряд правил для этого. STL вон тоже не многопоточная если на то пошло...
> Речь идет о моногопоточном, exception-safe GUI. Мне это позарез нужно.
> Таких библиотек (промышленных) только две: .NET framework и VCL (там
> все хуже, но все равно есть).

ТАКИХ нет. VCL — НЕпотокобезопасна, пора бы уже знать. Естественно, ее
можно использовать в многотредовом окружении, точно так же как и: MFC,
WTL, WinAPI, QT, GTK и прочие. То есть маршалируя графические вызовы в
нужный поток или используя только их потокобезопасное подмножество.

Ну а в качестве exception-safe — чем MFC или WTL не нравится?

> Я ставлю проблемы.

Какие? Которых нет?

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

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

sc>>>В Windows все элементы гуи, окна, это судя по названию...

TL>>А теперь "фишка": а вот в Дельфи не все элементы гуи являются окнами Windows!

D> Кстати, я так и не понял почему борландовцы свой TLabel сделали не на основе STATIC'а... И не только его...

— Ы!
— А почему "Ы"?
— А чтоб никто не догадался!
(к)

Хотя могу заметить, что определенный резон в этом есть, но с непривычки это несколько смущает...

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

TL>> 10 баллов! Первый признак дельфиста: "окно с обычной кнопкой OK, текст которой написан нестандартным шрифтом"! "Повбывав бы!" (к)

A>я чего-то тоже не пойму — а нахрен там нестандартный шрифт?
A>а если пользователь поменяет "тему десктопа" в Винде единообразно, что станет с этим нестандартным шрифтом?

— Ы!
— А почему "Ы"?
...

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

К>>Вот в винде он как раз многопоточный (для этого и существуют очереди сообщений у потоков).
К>>И этим пользуются разные подпольные компоненты — DDE, OLE.

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

Стоп-стоп-стоп! А при чем тут нижний уровень графики? Или Вы хотите сказать, что на двух мониторах нельзя будет рисовать одновременно?

В конце-концов, какой смысл: "запустить асинхронную операцию заливки экрана а самому в это время рисовать в другом месте"? И опять-таки никто не запрещает "запустить", а рисовать в это время в памяти — правда? И это относится скорее г GDI, чем к GUI, правда?

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

>> A>объясни в какой такой ОС существует многопоточный GUI?
>> A>в винде он однопоточный по определению (для этого и очередь сообщений)
>> Вот в винде он как раз многопоточный (для этого и существуют очереди
>> сообщений у потоков).

C>Он однопоточный в том смысле, что нельзя безопасно работать с
C>GUI-элементами, созданными в одном потоке, из другого потока (хотя
C>некоторые оконные сообщения действительно будут обрабатываться корректно).

В целом — нельзя. И со многими элементами системы тоже нельзя. И даже с памятью приходится ухищряться и самому писать синхронизацию. Вот только средства для обеспечения "многопоточного GUI" в Винде есть — те же очереди — и работают они отнюдь неплохо, правда? По крайней мере, свою задачу они выполняют...

Наверняка можно найти те или иные методы, которыми можно будет работать небезопасно с любым объектом любой ОС или платформы. Правда, говорят, AS/400 "совсем-совсем безопасная" — но сам я не видел...

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

C>Нет, Свинг — для профессиональных GUI-программистов, которые могут
C>обойтись и без редактора формочек.

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

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

>> C>Еще очень забавный опыт: создать в одном потоке дочернее окно с
>> C>родителем в другом потоке.
>> Вот только что опыт ставил. Результат — мрачный, но (через
>> пень-колоду) работает.

C>Угу, причем ломается в самых неожиданных местах (типа SetFocus).

C>Я как-то пытался довести такой подход до ума — в итоге наплевал, и стал
C>делать GUI полностью однопоточным.

Так, я где-то потерялся: придется поднимать старый проект и смотреть, как я "делал это" — самому интересно, а то вы тут заставили меня самому засомневаться в своей жизни...

Т.е. вы хотите сказать, что ежели дочернее окно и родительское окно будут иметь разные потоки, то возникнут проблемы? Хм... Можно огласить весь код? Можно в новую тему...

The Lex пишет:

> C>Я как-то пытался довести такой подход до ума — в итоге наплевал, и стал
> C>делать GUI полностью однопоточным.
> Так, я где-то потерялся: придется поднимать старый проект и смотреть,
> как я "делал это" — самому интересно, а то вы тут заставили меня
> самому засомневаться в своей жизни...
> Т.е. вы хотите сказать, что ежели дочернее окно и родительское окно
> будут иметь разные потоки, то возникнут проблемы? Хм... Можно огласить
> весь код? Можно в новую тему...

Возникнут обязательно. Я пытался заставить MDIChild'ов работать в своих
потоках. Оно, в принципе, работало. Но ОООЧЕНЬ глючно.

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

C>Я как-то пытался довести такой подход до ума — в итоге наплевал, и стал
C>делать GUI полностью однопоточным.

это примерно как писать многопоточные программы на VB(6)
в теории оно возможно но на практике лучше потратить время на что-нибудь другое

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

AE>Здравствуйте, d Bratik, Вы писали:
AE>И предпочитают делфи где-то по следующим причинам:

AE>2. За отсутствие шаблонов.
Не смертельно. в VB их тоже нет, в java и C# они недавно появились.

AE>3. За отсутствие возможности создания автоматических объектов (все объекты изначально является указателем).
Есть такая возможность — используй интерфесы и будет тебе счастье. Или напиши интерфейс обертку — получишь аналог SmartPointer'a
Например как в JCL :

Associates a resource, pointer or object reference, with a safeguard.

function Guard(Mem: Pointer; out SafeGuard: ISafeGuard): Pointer; overload;
function Guard(Obj: TObject; out SafeGuard: ISafeGuard): TObject; overload;
function Guard(Mem: Pointer; var SafeGuard: IMultiSafeGuard): Pointer; overload;
function Guard(Obj: TObject; var SafeGuard: IMultiSafeGuard): TObject; overload;

   var
     SafeGuard: ISafeGuard;
     Strings: TStrings;
   begin
     Strings := TStrings(Guard(TStringList.Create, SafeGuard));
     String.ReadFromFile('d:\delphi\jcl\source\JclBase.pas');
     // code to manipulate strings goes here
     Strings.SaveToFile('d:\delphi\jcl\source\JclBase.pas');
   end;

Project JEDI

AE> Соответственно приходистя вручную вызывать конструктор/деструктор (для чего и TRY..Finnaly)
ЭЭ а в каком языке не нужно вручную вызывать конструктор?

AE>4. За отсутствие множественного наследования
в Java тоже его нет, в мусор java!
AE>5. За отсутствие возможности перегрузки операций
не смертельно. см п. 4
AE>6. За WITH благодаря которому код становится не читабельным до ужаса...
так не используй его! goto тоже в Delphi есть , это же не значит что его нужно пихать где попало!
AE>7. За дикую абстрактность от GUI модели, благодаря чему некоторые события не доступны
Кто тебе мешает отделить модель? Зачем все пихать в одну форму? можно разбить на фреймы, на отдельные
модули...
AE> реализован Handle у компонентов — просто бестселлер, понял когда случайно вызвал в
AE> деструкторе.
нормально реализован, чтобы ресурсы не жрать когда handle не нужен.
AE>12. За отсутствие менеджера конфигураций. Так чтобы сделать Debug и Release хотябы, и пользоваться просто переключая их.
AE>13. За дикий размер EXE, если конечно же не юзать пакаджи.
Дался тебе этот размер. Ты что програмки на дискетках распространяешь?

и вообще, а почему таки не юзать пакаджи? Только вместо стандартных, создать свои — с теми модулями котрые тебе нужны.
Получишь 1-2 пакета размером 1-2 мб + остальные файлы проекта (exe,dll) по 10-90 кб.
Дистрибутив из 300 проектов-плагинов вместо 100 мб занимает 12 мб.
Сложно ставить кучу файлов ? так сделай инсталлятор! и авто обновление .
AE>14. За то что ошибочная работа встроенных функций ведет к генерированию исключения, а не возврату кода ошибки. При этом во многих случаях приходится писать просто try ... except end; чтобы пропустить эту фичу.
Такая же модель в java и С. Если сделать через возврат кода ошибки, то есть вероятность что ты не вставишь код проверки
результата (ты же давишь исключения не глядя) и ошибка произойдет гораздо позже и в другом месте.И опять будут крики
что Delphi ламерская система


AE>15. За то что она не MDI. Это ужасно "УДОБНО". Приходится очищать рабочий стол перед открытием делфи, да и две запущенные — это головняк ("КРУТО"), поскольку никогда не знаешь в редакторе какой находишся. Иногда по ALT-TAB переключается только редактор, а главное окно нет.
Единственный случай кода тебе нужны две IDE — это когда отлаживаешь расширения среды. В остальных случаях используем ProjectManager
для работы. Открываем там N проектов...

AE>16. За WITH благодаря которому дебаггер не показывае значение переменных типа with TComeCObject.Create(...) do Visible := TRUE;
AE> Значение Visible — не увидишь никогда. Только если with SomeObject do SomeProperty := SomeValue; то в ТОЛЬКО окне свойств надо подставить SomeObject.SomeProperty и только тогда будет значение
Не пользуйся им ! см п. 6
AE>17. За дебаггер который видит стек вызовов исключительно ограниченный модулями, пути которых включены в проект.
Это потому что dcu из $(Delphi)\lib собраны без отладочной информации (см п 13). Хочешь видеть весь стек — зайди в настройки
и поставь галочку use Debug DCUs и не мучайся с путями. RTFM!

AE>18. За отсутствие оператора "?". Есть только два псевдоаналога — варианты функции ifthen. При этом нормально работать можно со строкой и Integer-подобными значениями.
AE> Когда речь идет об объекта то тогда запись выростает до TType(ifthen(...,Integer(Object1),(object2)) — грустно...
Ну напиши нужные тебе ifthen (работы на 5 минут), добавь их в отдельный модуль и не грусти.

AE>19. За компилятор, который хавает на ура запятую без указания последнего необязательного параметра функции.
AE> Т.е. если function f(p1: Integer; b1: Boolean=false; B2: Boolean = false), то такое прокатит на ура — f(1,false,);
Это ошибка парсинга на компиляцию это никак не влияет . В D7 эта ошибка исправлена. Можно подумать в компиляторах C ранних версий нет
ошибок. (в мусор их!)
AE>20. За директивы компилятора сделанные в стиле коментариев и мещающие коментированию текста их содержащего
используй // или (* *)
если в коде уже есть комметарии то его тоже неудобно комментировать

AE>21. За отсутствие нормального хелпа к системным функциям.
Поставь MSDN и эксперт для поиска в нем из среды. Или ты хочешь чтобы справка Delphi дублировала весь MSDN

AE> Для того чтобы определить где находится описание сетевой
AE> функции нужно выполнять поиск по каталогу сырцов. К примеру NetWkstaGetInfo которая вообще отсутствиет в
AE> стандартных сырцах
Можно подумать в VC 6 есть все-все API фунции?

AE> Ламерская система....
ага и компонета TNetWkstaGetInfo нет, ламерская система!

AE>23. За то что нельзя создать два пакета содержащие модули с одинаковыми названиями — среда не позволит, будет каждый раз ругаться что Пакет ХХХ использует модуль УУУ, который уже содержится в ХХ1 — это очень удобно, в с++ такого не добиться
Можно , если их не ставить в среду и использовать только в runtime . Как IDE определит из какого пакета брать модуль YYY?


Вы не любите кошек? вы просто не умеете их готовить!

Кроче пост полностью аналогичный первому в ветке.
Я не говорю что Delphi идеальная среда, и для нового проекта я бы выбрал C# . Но ИМХО когда C# еше не было, Delphi
был лучшим инструметом для быстрой разработки мордочек для работы с базами данных (всякие АСУ и т.д.), и сейчас остается если машины слабые
Проблемы начинаются когда инструмент начинают использовать не по назначению. Например
пытатся писать на Delphi игры или маленкие программы или хакерские утилиты

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

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

AE>>>12. За отсутствие менеджера конфигураций. Так чтобы сделать Debug и Release хотябы, и пользоваться просто переключая их.

ABS>>А зачем? Во всех конфигурациях размеры файлов и скорость выполнения одна и таже. Не забивай себе голову

AE>Да меня не скорость и размер волнуют — просто в Debug-версии нужны особые фичи отладки например, что можно на уровне "IFDEF" выбросить из релиза. Так и делаю, о приходится вручную менять список CONDITIONS, а есть нежелательный "человеческий фактор".

А у нас для сборки release версии есть сервер сборки. Там и директивы нужные подставляются и инсталлятор генерится и тд.
Никакого человеческого фактора — все исходники из StarTeam, управление через web интерфейс.

Ну а для начала для сборки релиза достаточно батника обрашающегося к dcc32. Все директивы можно там указать.
или посмотри на это:

WANT automates the process of building, testing, and packaging applications and libraries much like Jakarta Ant does. WANT is written in Borland Delphi.
https://sourceforge.net/projects/want/

отличная вещь, уже 3 года пользуемся.

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

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

sc>>В Windows все элементы гуи, окна, это судя по названию...


TL>А теперь "фишка": а вот в Дельфи не все элементы гуи являются окнами Windows!

Это для экономии ресурсов, в win95 с этим были проблемы — ограничение на число hwnd. И машины с 16 мб
были не редкость (и сейчас такие есть).

или например похожий принцип используется в TCanvas —
когда ты например, меняшь цвет кисти или шрифт — это означает что нужно создать новый объект GDI.
Тк в win95 было ограничение на их количество (кажется не больше 16 000) то все гди объекты реально создаются в
только при обращении к ним

procedure TCanvas.Ellipse(X1, Y1, X2, Y2: Integer);
begin
  Changing;
  RequiredState([csHandleValid, csPenValid, csBrushValid]); <<----здесь
  Windows.Ellipse(FHandle, X1, Y1, X2, Y2);
  Changed;
end;

procedure TCanvas.RequiredState(ReqState: TCanvasState);
var
  NeededState: TCanvasState;
begin
  NeededState := ReqState - State;
  if NeededState <> [] then
  begin
    if csHandleValid in NeededState then
    begin
      CreateHandle; <<----------- вот  
      if FHandle = 0 then
        raise EInvalidOperation.CreateRes(@SNoCanvasHandle);
    end;
    if csFontValid in NeededState then CreateFont; <<<---
    if csPenValid in NeededState then CreatePen;   <<--
    if csBrushValid in NeededState then CreateBrush; <<--
    State := State + NeededState;
  end;
end;

и для оконных компонетов такая же система — handle создается только тогда когда он нужен.
Непонятно зачем тебе нужно чтобы все было окнами ? Вот в XAML тоже есть только одно окно, и что это плохо?

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

К>>Вот в винде он как раз многопоточный (для этого и существуют очереди сообщений у потоков).
К>>И этим пользуются разные подпольные компоненты — DDE, OLE.

A>очереди сообщений относятся к приложению а не к графическому движку.
A>разве можно из двух потоков одновременно (а не ставя запросы в очередь) рисовать на одном DC?
A>или например запустить асинхронную операцию заливки экрана а самому в это время рисовать в другом месте
А зачем ? Можно создать в памяти битмап и заливать его цветом в другом потоке. Потом послать сообщение SendMessage основному потоку и
передать в нем адрес битмапа... или нужно видеть как он заливает и моргает при перерисовке ?
в чем смысл такой многопоточности?
в тех же игрушках есть два буфера в один рисуют , другой показывают

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


A>писано все было на VC++ 6.0 и MFC, и впоследствие портировано на Макинтош.

Можешь описать, хотя бы в двух словах, как портировали под Мак?