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

IT>>>А почему в одном случае 2, а в другом 10?

NB>>да просто так

IT>Т.е. пристреливаем контролы к форме

отступы можно

NB>>то-ли дело в гугл-группах.

IT>А как там сделано, может и мы идейку потырим.

да просто есть возможность приложить к сообщению файл.
некоторые вставляют картинки в тело письма. как -- х.з

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

IT>Где бы посмотреть скриншотик образцово показательной картинки таких гуёв. А то что-то меня мучают смутные подозрения.

все зависит от того, что ты понимаешь под словом образцово.
вот простенький просмотрщик текстовых словарей



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

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

FR>И что?
FR>Ну введут в C# 3 некторые минимальные функциональные возможности, для использования которых не надо перестраивать мышление и плюс встроят пару специализированных DSL, это же как небо и земля по сравнение с Nemerle.

На Немерле можно программировать как на C#. Это значит, что цена входа практически равна нулю. Ну, а там несколько раз подсмотреть за другими, стейку почитать... и глядишь через недельку ты пуже пишешь на C#++, а через месяц другой вообще на совсем другом языке. Я это уже наблюдал (хотя казалось бы язык тольк появился).

FR>Взять тот же C++, большинство не пользуются метопрограммированием, в лучшем случае используют готовые библиотеки написанные с его использованием. И вообще здесь по моему переоценивают важность метопрограммирования.

Дык и чем хуже Немерле? Будет точно так же. Кто-то будет использовать его как улучшеный C# (как когда-то С++ использовали как улучшенный С), а кто-то будет писать мета-код для общего использования.

Вот, шутки, шутками, а Остиновская работа рожденная в процессе доказательства, что Немерле не ишак (т.е. в процессе пенисометрии) в предь будет включаться в план ежедневного тестирования Немерла и будет доступна всем.

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

FR>Если привык к стеку то все просто.

Да, да... Если привык к стеку... Если привык к программированию в АСТ... Если привык... Большинство людей не будет привыкать к убогости. Ведь есть неплохая альтернатива.


VD>>С увдовольствием прочел бы про него статью, особенно если она будет на нашем сайте/в нашем журнале. Но копать специально желания нет. Думаю, что со мной согласятся очень многие.

FR>http://www.forth.org.ru/

Спасибо, мне эта ссылка на фиг не ппала. Ты дай ссылку на статью на русском. А то я там что-то ничего хорошего не нашел.

VD>>Здорово, но писать свои языки вместо работы как-то не хочется. Меня олее устраивает качественный, высокоуровневый, гибкий язык программирования общего назначения который можно подстраивать под свои нужды.

FR>Там только идея одинаковая а реализации совершено разные, и смысл их сравнить есть.

Сравни, а мы опубликуем.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Вот хочу я прикрутить спел-чекер. Движок есть. Что я должен задать в дизайнере, чтобы RichTextBox начал с ним работать? А в Tk уже всё (я вверху выделил) написано. Вот и вся разница.

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

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

FR>Так он не обязывает делать вручную, есть и RAD'ости, например:
FR>http://vtcl.sourceforge.net/
FR>http://vtcl.sourceforge.net/?x=screen

Ну, а теперь подытоживаем... Мы получили такой же дизайнер как в C# с мааааленькими оговорочками. Он выгдядит очень убого (думаю, так же убого в нем работать), расширяется не средсвами языка на котором ведется разработка и не имеет моря готовых контролов от третьих (да хоть от каких) производителей.

Ну, и чем вы тут хвастались? Убогостью? Ее и так кругом хватает.

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

VD>Ну, а теперь подытоживаем... Мы получили такой же дизайнер как в C# с мааааленькими оговорочками. Он выгдядит очень убого (думаю, так же убого в нем работать), расширяется не средсвами языка на котором ведется разработка и не имеет моря готовых контролов от третьих (да хоть от каких) производителей.

Он *расширяется* средсвами языка на котором ведётся разработка, к нему есть (ну ладно, в 2000 году, когда я последний раз использовал Tcl/Tk было, а сейчас не знаю) несколько наборов виджетов на все случаи жизни. В *море* готовых контролов нет острой необходимости, потому что все наличные виджеты легко расширяются и модифицируются.

Что-бы не быть голословным приведу пример, который я использовал.
Использовался код

# <s>------------------------------------------------------------------</s>
# EXAMPLE: appointment schedule widget
# <s>------------------------------------------------------------------</s>
# Effective Tcl/Tk Programming
# Mark Harrison, DSC Communications Corp.
# Michael McLennan, Bell Labs Innovations for Lucent Technologies
# Addison-Wesley Professional Computing Series
# ======================================================================
# Copyright © 1996–1997 Lucent Technologies Inc. and Mark Harrison
# ======================================================================

Вот код создания виджета (коментарии жирным — мои):

#  USAGE:  appointment_create <win>
#
#  Creates one page in an appointment book.  This includes a text
#  widget with some special tags and bindings, and a scrollbar.
#  Information is loaded into the page via appointment_load.
# ----------------------------------------------------------------------
proc appointment_create {win} {
   frame $win -class Appointment

   scrollbar $win.sbar -command "$win.text yview"
   pack $win.sbar -side right -fill y

    #Тут создаётся текстовый виджет (аналог RichTextEdit)
    # с вертикальным скролбаром с двумя колонками: 
    # одна 2 сантиметра от левого края и с 
    # правым выравниванием, другая - 2,4 см с левым.
    #
   text $win.text -background white -wrap word \
       -cursor left_ptr -tabs {2c right 2.4c left} \
       -yscrollcommand "$win.sbar set"
   pack $win.text -side left -expand yes -fill both

   #
   # Set up tags for the various text styles...
   #
     # Тэги - это нечто вроде стилей
     # Они имеют ряд свойст, которые исменяют
     # как внешний вид так и поведение элементов,
     # к которым эти теги привязаны. То есть,
     # изменени некого визуального атрибута в тэге
     # изменяет внешний вид всех элементов к которым
     # этот тег привязан. К одному элементу можно
     # привязывать много тегов.
     #
     # Тут конфигурируются теги title, date, hour, 
     # comment, stripe, space.
     # 
     # Строчка 'option get $win titleFont Font' это
     # получение значений из внешних конфигов.
     # На 'X' это родной механизм, по виндами - эмуляция
     
   $win.text tag configure title \
       -font [option get $win titleFont Font]

   $win.text tag configure date \
       -font [option get $win dateFont Font]

   $win.text tag configure hour \
       -font [option get $win hourFont Font]

   $win.text tag configure comment \
       -lmargin1 2.4c -lmargin2 2.4c \
       -font [option get $win commentFont Font]

   $win.text tag configure stripe \
       -background [option get $win stripeBackground Background] \
       -foreground [option get $win stripeForeground Foreground]

   $win.text tag configure space -spacing1 5

   #
   # Set up bindings to handle appointment editing...
   #
   set btags [bindtags $win.text]
   set i [lsearch $btags Text]
   if {$i >= 0} {
       set btags [lreplace $btags $i $i]
   }
   bindtags $win.text $btags

    #Тут ничего необычного - обработка событий клавиатуры...
   bind $win.text <KeyPress> "appointment_insert $win %W %A"
   bind $win.text <Control-KeyPress-h> "appointment_backspace $win %W"
   bind $win.text <KeyPress-BackSpace> "appointment_backspace $win %W"
   bind $win.text <KeyPress-Delete> "appointment_delete $win %W"
   bind $win.text <KeyPress-Tab> "appointment_next $win %W; break"
   bind $win.text <KeyPress-Down> "appointment_next $win %W; break"
   bind $win.text <KeyPress-Up> "appointment_prev $win %W; break"
   bind $win.text <KeyPress-Left> "appointment_left $win %W; break"
   bind $win.text <KeyPress-Right> "appointment_right $win %W; break"

   #
   # Bind to the "comment" fields to let the user position
   # the cursor...
   #
    #... и нажатий мыши
   $win.text tag bind comment <ButtonPress-1> "
       focus %W
       %W mark set insert @%x,%y
   "

   return $win
}

Теперь пример добавления строчек в виджет:

# ----------------------------------------------------------------------
#  USAGE:  appointment_load_slot <win> <slot> <appmt> <allSlots>
#
#  Adds a single line to the appointment book <win>.  Each line
#  represents one time slot.  <slot> contains the hour like "8:00am".
#  <appmt> is a list containing the alarm setting and the comment
#  message.  <allSlots> is a list of all of the slots, in the order
#  that they are displayed on the page.
# ----------------------------------------------------------------------
proc appointment_load_slot {win slot appmt allSlots} {
   if {[string match "*:00" $slot]} {
       set htags "hour space"
   } else {
       set htags "hour"
   }
     # htags - это набор тэтов, согласно которым
     # меняется внешний вид текста
     # Текст добавляется уже с тэгами (последняя переменная).
   $win.text insert end "\t$slot\t" $htags

   appointment_load_bell $win $slot $appmt

   set pos [lsearch $allSlots $slot]
   if {$pos % 2 != 0} {
       set ctags "comment stripe"
   } else {
       set ctags "comment"
   }
   set mesg [lindex $appmt 1]
   $win.text insert end "$mesg\n" $ctags
}

Переход между строчками:

# ----------------------------------------------------------------------
#  USAGE:  appointment_next <twin>
#
#  Moves to the next appointment slot on the text widget <twin>.
# ----------------------------------------------------------------------
proc appointment_next {win twin} {
   set range [$twin tag nextrange hour insert]
   if {$range != ""} {
       set index [lindex $range 0]
       set range [$twin tag nextrange comment $index]
       set index [lindex $range 0]
       $twin mark set insert $index
   }
   $twin see insert
}

Весь код приводить естественно не стану.
Вот внизу картинка того как оно выглядит. Поставить курсор куда-то кроме поля для ввода текста нельзя. Автоматически развдигаются строчки для ввода кода. По умолчанию поле со временем белое, я его сделал желтым что-бы выделить. Добавлю еще, что не смотря на то, что исходно Tcl на поддерживает никакого ООП, сами виджеты традиционно работают по вполне ООП схеме.
Например, .but configure ....
Тут .but — это кнопка, объект-получатель сообщения 'configure' с параметрами ..... Достигается это путём создания процедуры которая и занимается "диспетчеризацией" сообщений. В далёком 2000 "pure tcl" виджеты в разных виджетсетах работали с нормальной скоростью.
То есть то что получился полноценный виджет, отличающийся довольно радикально от исходного текстового. Работает на куче платформ.

А теперь внимание вопрос, как расширить RichTextEdit до чего-то подобного? Вопрос дялеко не праздный, так как попытавшись изменить поведение какого-то контрола, я вдруг с удивлением узнал, что у него половина методов не виртуальные, и наследников создавать бесполезно, а переписывать с нуля — не спортивно.



VD>Ну, и чем вы тут хвастались? Убогостью? Ее и так кругом хватает.

А я уж думаю думаю, неужели у Влада 5 копеек нету? Тогда просвети, Влад, ты зачем сцинтилу прикручивал я Янусу? Почему не расширил функциональность стандартных котролов? Так вот, Влад, "убожество" это когда, чтобы что-то сделать приходся брать сторонний контрол, или переписывать всё с нуля. "Коде реюзе", блин.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

VD>>Ну, а теперь подытоживаем... Мы получили такой же дизайнер как в C# с мааааленькими оговорочками. Он выгдядит очень убого (думаю, так же убого в нем работать), расширяется не средсвами языка на котором ведется разработка и не имеет моря готовых контролов от третьих (да хоть от каких) производителей.

ANS>В *море* готовых контролов нет острой необходимости, потому что все наличные виджеты легко расширяются и модифицируются.

Да? Ну, тода тебе не составит труда быстренько продемонстрировать мне расширение уж низнаю чего, но так чтобы оно по функциональности было как Инфрагистевский или ДевЭеспресовский грид. ОК? А до тех пор не надо смешить окружающих.

ANS>А теперь внимание вопрос, как расширить RichTextEdit до чего-то подобного? Вопрос дялеко не праздный, так как попытавшись изменить поведение какого-то контрола, я вдруг с удивлением узнал, что у него половина методов не виртуальные, и наследников создавать бесполезно, а переписывать с нуля — не спортивно.

RichTextEdit это обертка для виндового контрола. Если что-то не расширяется средствами самого контрола, то всегда можно ловить виндовые сообщения.
Короче это переход с обсуждения средсва разработки н набор контролов. ГУИ на базе tcl которые я видел были на редкость убогими. Так что его рутость мне даже обсждать не хочется.

Предлагаю вернуться к исходной теме и ответить таки на вопрос почему на C# я могу созавать гуи без подпорок. А для С++ мне нужные разные подпорки вроде внешних кодогенераторов или отдельного скриптового языка tcl?

VD>>Ну, и чем вы тут хвастались? Убогостью? Ее и так кругом хватает.

ANS>А я уж думаю думаю, неужели у Влада 5 копеек нету? Тогда просвети, Влад, ты зачем сцинтилу прикручивал я Янусу? Почему не расширил функциональность стандартных котролов?

А Сцинтила и есть контрол расширяющий функциональность. Сделать качественный редактор кода из RTF-редактора нельзя в принципе. У них разные принцыпы работы и задачи.

ANS> Так вот, Влад, "убожество" это когда, чтобы что-то сделать приходся брать сторонний контрол, или переписывать всё с нуля. "Коде реюзе", блин.

Не. Возможность взять сторонний контрол или разработать его самому — это как раз универсальное решение позволяющее не мериться с убогостью окружающей среды. А вот ссылаться на разные tcl при обсуждении убогости дизайна С++ — это как раз красноречивешее свидетельство того, что язык не полноценен и требует моря подпорок для реальной жизни.

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

VD>RichTextEdit это обертка для виндового контрола. Если что-то не расширяется средствами самого контрола, то всегда можно ловить виндовые сообщения.
VD>Короче это переход с обсуждения средсва разработки н набор контролов. ГУИ на базе tcl которые я видел были на редкость убогими. Так что его рутость мне даже обсждать не хочется.

VD>Предлагаю вернуться к исходной теме и ответить таки на вопрос почему на C# я могу созавать гуи без подпорок. А для С++ мне нужные разные подпорки вроде внешних кодогенераторов или отдельного скриптового языка tcl?

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

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

VD>Ну, а теперь подытоживаем... Мы получили такой же дизайнер как в C# с мааааленькими оговорочками. Он выгдядит очень убого (думаю, так же убого в нем работать), расширяется не средсвами языка на котором ведется разработка и не имеет моря готовых контролов от третьих (да хоть от каких) производителей.

У тебя все что не NET убого, так что это не аргумент. Ну и посмотрим на сколько неубогим станет NET если будет подерживать столько же платформ сколько и tcl/tk.
Он может расширятся как и средствами языка на котором ведется разработка так и с помощью си — с++
На него достаточно много готовых контролов от других производителей.

VD>Ну, и чем вы тут хвастались? Убогостью? Ее и так кругом хватает.

Нет просто ты достаточно часто ничего ни зная о предмете любишь делаеть безапиляционные заявления.

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

NB>а вы разговор о теории упругости тоже сведете к обсуждению убогости С++?

А что поделаешь, если это не далеко от истины
C++ — устаревший язык, с дизайном, отвечающим интересам комитета, но никак не реальной жизни.

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

NB>>а вы разговор о теории упругости тоже сведете к обсуждению убогости С++?

IT>А что поделаешь, если это не далеко от истины

только вот к теории упругости не имеет никакого отношения

IT>C++ — устаревший язык, с дизайном, отвечающим интересам комитета, но никак не реальной жизни.

ну а по поводу устаревший -- фортран тоже устаревший.
тем не менее на нем работает куча народа.
и будет работать дальше.

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

IT>C++ — устаревший язык, с дизайном, отвечающим интересам комитета, но никак не реальной жизни.

Выделенное не правда. Комитет всего лишь систематизировал часть предложений пользователей C++. Лишь небольшую часть предложений.

Если почитать Страуструпа, то становится понятно, что у C++ были настолько разнородные пользователи, в настолько разных предметных областях C++ применялся, насколько разные требования к нему предъявлялись, настолько разные по своему характеру и целям люди входили в комитет, что хорошо еще, что язык C++ вообще получился таким, какой он есть. Могло быть гораздо хуже.

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

NB>>>а вы разговор о теории упругости тоже сведете к обсуждению убогости С++?
IT>>А что поделаешь, если это не далеко от истины
NB>только вот к теории упругости не имеет никакого отношения

Зато к теме топика имеет самое непосредственное

IT>>C++ — устаревший язык, с дизайном, отвечающим интересам комитета, но никак не реальной жизни.

NB>ну а по поводу устаревший -- фортран тоже устаревший.
NB>тем не менее на нем работает куча народа.

А какая куча народа на нём не работает!

NB>и будет работать дальше.

Флаг в руки и барабан на шею. Впрочем, не думаю, что эти несчастные работают на фортране по собственной воле. А если им или они сами себе всё же внушили такую глупость, то не думаю, что они сами же полагают, что находятся на острие передовых технологий

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

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

IT>>C++ — устаревший язык, с дизайном, отвечающим интересам комитета, но никак не реальной жизни.
E>Выделенное не правда. Комитет всего лишь систематизировал часть предложений пользователей C++. Лишь небольшую часть предложений.

Почему неправда? Я про небольшую часть и говорю. Небольшую часть, отвечающую интересам комитета.

E>Если почитать Страуструпа, то становится понятно, что у C++ были настолько разнородные пользователи, в настолько разных предметных областях C++ применялся, насколько разные требования к нему предъявлялись, настолько разные по своему характеру и целям люди входили в комитет, что хорошо еще, что язык C++ вообще получился таким, какой он есть. Могло быть гораздо хуже.

Кто знает, может быть хуже, а может и гораздо лучше

Вот расскажи мне. Ты когда нибудь пользовался такой фигнёй в плюсах как mutable? Я никогда. Не понадобилось за 10 лет ни разу А вот свойствами (расширениями от производителей) пользовался во всю как только узнал, что они есть. Потому что удобно. И теперь ты мне можешь до посинения рассказывать, почему mutable нужен в языке, а property, которую реализовать фигня как два байта об асфальт, оказалась вещью, по мнению Страуструпа не нужной и бесполезной.

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

NB>>только вот к теории упругости не имеет никакого отношения

IT>Зато к теме топика имеет самое непосредственное

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

NB>>ну а по поводу устаревший -- фортран тоже устаревший.
NB>>тем не менее на нем работает куча народа.

IT>А какая куча народа на нём не работает!

как и на .Нет

NB>>и будет работать дальше.

IT>Флаг в руки и барабан на шею. Впрочем, не думаю, что эти несчастные работают на фортране по собственной воле. А если им или они сами себе всё же внушили такую глупость, то не думаю, что они сами же полагают, что находятся на острие передовых технологий

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

IT>Что же касается плюсов, то от острия они тоже уже отдалились на весьма приличное расстояние.

а где нынче острие, интересно?

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

IT>Вот расскажи мне. Ты когда нибудь пользовался такой фигнёй в плюсах как mutable? Я никогда. Не понадобилось за 10 лет ни разу

иногда нужно. делал linked умный указатель.

IT>А вот свойствами (расширениями от производителей) пользовался во всю как только узнал, что они есть. Потому что удобно. И теперь ты мне можешь до посинения рассказывать, почему mutable нужен в языке, а property, которую реализовать фигня как два байта об асфальт, оказалась вещью, по мнению Страуструпа не нужной и бесполезной.

без них вполне можно жить. если тяжело, то можно эмулировать.
а const_cast эмулировать нельзя.

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

IT>Почему неправда? Я про небольшую часть и говорю. Небольшую часть, отвечающую интересам комитета.

Потому что не было такого понятия, как "интересы комитета". Были интересы отдельных групп в коммитете.

IT>Вот расскажи мне. Ты когда нибудь пользовался такой фигнёй в плюсах как mutable? Я никогда. Не понадобилось за 10 лет ни разу

Пользовался. И пользуюсь время от времени (где-то раз в полгода). В последний раз использовал для проведения отложенных вычислений в константном объекте. Т.е., есть объект, доступный через константный указатель или ссылку. Обычно у него вызваются всего несколько самых частоиспользуемых методов. Эти методы тривиальны и эффективны. Но иногда требуется вызвать некий "тяжелый" метод, который должен провести ряд дорогих преобразований (сериализация нескольких объектов для получения уникальной бинарной строки). Вот в этом методе mutable оказывается восстребован.

IT> А вот свойствами (расширениями от производителей) пользовался во всю как только узнал, что они есть. Потому что удобно. И теперь ты мне можешь до посинения рассказывать, почему mutable нужен в языке, а property, которую реализовать фигня как два байта об асфальт, оказалась вещью, по мнению Страуструпа не нужной и бесполезной.

А вот у меня никогда ни возникало желания использовать property.

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

VD>Да? Ну, тода тебе не составит труда быстренько продемонстрировать мне расширение уж низнаю чего, но так чтобы оно по функциональности было как Инфрагистевский или ДевЭеспресовский грид. ОК? А до тех пор не надо смешить окружающих.

Ну, Влад, я не собираюсь один мерятся пиписькой с сумарной длиной у двух команд, не первый год создающий этот самый грид.

VD>Предлагаю вернуться к исходной теме и ответить таки на вопрос почему на C# я могу созавать гуи без подпорок.

Пока это не было продемонстрировано.

VD> А для С++ мне нужные разные подпорки вроде внешних кодогенераторов или отдельного скриптового языка tcl?

Проблемы С++ меня не интересуют, но, неужели в программе на С++ нельзя использовать сцинтилу или вышеупомянутый грид?

VD>Сделать качественный редактор кода из RTF-редактора нельзя в принципе.

Вот это убожество и есть.

ANS>> Так вот, Влад, "убожество" это когда, чтобы что-то сделать приходся брать сторонний контрол, или переписывать всё с нуля. "Коде реюзе", блин.

VD>Не. Возможность взять сторонний контрол

Это уневерсальное решение?

VD>или разработать его самому —

это, да универсальное. Но есть одна загвоздка, и С++ и С# и Tcl одинаково универсальны. Так о чем разговор?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

VD>>Предлагаю вернуться к исходной теме и ответить таки на вопрос почему на C# я могу созавать гуи без подпорок.

Да просто из-за политики микрософта. По дефолту с VC идет недоношеный обрубок MFC, хотя даже его можно довести до ума. Взять например комерческие MFC-расширения типа BCG. Вполне можно программировать, достаточно грамотно сделано.

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

NB>а const_cast эмулировать нельзя.

(const XXX*)? Или ты dynamic имел ввиду?