Разрабатываю чат для локальной сети - Alpha Chat

[Accord]

Целенаправлено разрабатываю для продажи.

Чат пока находится в следующей стадии:
Работа сразу после загрузки, обмен сообщениями в общем чате, аватары, системные сообщения, работа по протоколу IP-multicast/UDP.
Среда разработки VC++(, библиотеки ATL/WTL/STL/Win API).
Перешёл на MFC.

Буду благодарен за любую помощь в разработке.

 

[HuMmmBug]

а изучение текущего рынка ПО указало на необходимость создания такого ПО?
неужели нет подобных?
borgchat, IChat

 

[Accord]

<!--QuoteBegin-QUOTE+HuMmmBug-->
<span class="vbquote">(QUOTE @ HuMmmBug)</span><!--QuoteEBegin-->а изучение текущего рынка ПО указало на необходимость создания такого ПО?
неужели нет подобных?
borgchat, IChat[/quote]
по-моему это не помощь, а попытка отговорить.
Приведу более веские доводы вот цитата из swrus digest

From: Vladimir Katalov <kitten@elcomsoft.com>


Привет,

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

Очень похоже на то Тем более, что можно собрать все лучшее, что
есть у конкурентов, и избавиться от их недостатков... У нас нет ни
одного "уникального" продукта, но проблем с продажами не испытываем
Скорее, даже так: чем "оригинальнее" продукт, тем меньше заказов.

Sincerely yours,
Vladimir

Vladimir Katalov
Managing Director
Elcom Ltd.

 

[admin]

Accord
Accord

по-моему это не помощь, а попытка отговорить.

нет
это грамотная критика.
определись для начала с идеей.
чем твой чат круче других.
попробуй сделать универсальный Intranet|Internet чат. Т.е. чат совмещающий Общение по локальной сети и по интернету. Например меня задирает сидеть в Nassi и в Mirc одновременно. Но не все у нас любят мегафейс Мирки. Сделай поддержку ICQ. Чат должен быть безопасным. Это не преувеличение. Сделай к нему plug-ins дабы не тормозить развитие. Вот тогда это будет ЧАТ. Т.е. идею развить можно, но реализовать... Это вопрос другой. Ну если очень хочется - получится

 

[Accord]

Серёга
С идеей я определился.
Да, это будет Intranet|Internet чат совместимый с ICQ.
Шифрование трафика будет поддерживаться.
На счёт плагинов - хорошая идея. Возьму на заметку.
Есть ещё множество идей, нужно будет выделить время на написание спецификации.

Итого - для начала нужно разработать хотя бы Intranet часть.
Потом начать продвигать, а после уже развивать продукт до Internet версии.

 

[AlexGin]

Accord

Я полагаю, следует сначала
определиться с "профилем" потенциального
пользователя этой программы...

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

А мне сейчас уже и нет охоты все переделывать
Если только делать новый проект

 

[AlexGin]

Accord

В составе применяемых технологий:

Среда разработки VC++, библиотеки ATL/WTL/STL/Win API.

BTW - почему нет решимости применять MFC ?

Лично я более шести лет занимаюсь на MFC
(хотя последние год-полтора уже и на .NET - C#)
и вижу, что для разработки Desktop Applications
MFC - великолепная библиотека классов

Если нужно какое-то содействие по
освоению самой библиотеки MFC -
я готов оказать любое содействие...

 

[Guest]

Лично я более шести лет занимаюсь на MFC
[..skipped..]
и вижу, что для разработки Desktop Applications
MFC - великолепная библиотека классов :huh:

Уважаемый, а с чем вы сравнивали? Поподробнее если можно.

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

 

[AlexGin]

Насчет того, что MFC - отличная библиотека
классов можно спорить или не спорить. ИМХО
для разработки настольных приложений
это вполне справедливо.
Такого набора дополнительных библиотек классов и
ActiveX компонентов (причем проффесионального
уровня) - сложно еще где-то найти...

В процессе сравнивания с VCL (C-Builder)
я определил:

Недостатки VCL:
1) После разработки мы далеко не
всегда получаем стабильное приложение, есть
вероятность различных глюков (как самого билдера,
так и VCL) - это заметили я и мои товарищи, работающие
с VCL.
2) Качество документации и примеров - оставляет желать...
Ни какого сравнения с четкой организацией MSDN.
3) Дополнительных компонентов - вроде и много, но (как
правило) они не того качества...
4) При разработке настольных приложений -
меньше вариантов оптимизации
"customizing" GUI для пользователя
(по сравнению с MFC и доп-библиотеками к MFC).

Достоинства:
1) Разработка распространенных решений - диалоги,
базы данных - идет быстрее.
2) Библиотека VCL проще при начальном изучении.

Что же касается .NET
- это новый продукт. Он весьма
удобен при разработке, и я полагаю что за ним
большое будущее. Однако, отмечу и его недостатки:

1) Непростой (с точки зрения синтаксиса) вызов
функций Windows API - для этого следует применать
аттрибут импорта DLL и вспомогательные (небозопасные)
типы данных. Надеюсь, в будущих версиях это упростят.
Как и некоторые другие особенности "interop".
2) При установке приложения на .NET
на машине клиента придется устанавливать .netFrameWork
(а это еще под 70 MB программного кода). Это не всегда
приемлемо.
2) Отсутствие шаблонов (templates) - надеюсь,
в будущих версиях это добавят.
3) При разработке настольных приложений -
меньше вариантов оптимизации
"customizing" GUI для пользователя
(по сравнению с MFC и доп-библиотеками к MFC).

Достоинства .NET:
1) Писать программы стало намного легче чем в том же
MFC или VCL.
2) Огромная и богатая библиотка классов, доступная разработчику.
3) Результаты намного стабильнее чем в MFC или VCL.
4) Большое количество различних компонентов для .NET
(хотя в будущем - их будет еще больше).

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

 

[Guest]

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

Я признаю, что я слабо знаю Windows, но неужели MFC предоставляет компоненты ActiveX???

В процессе сравнивания с VCL (C-Builder)
я определил:

Недостатки VCL:
1.После разработки мы далеко не
всегда получаем стабильное приложение, есть
вероятность различных глюков (как самого билдера,
так и VCL) - это заметили я и мои товарищи, работающие
с VCL.
и т д

С VCL не знаком. Но про стабильность его наслышан.
Без аргументов (ссылок) пока это просто гон.

А из серии MFC расскажите мне про использование контейнеров MFC в потоке, созданном не с помощью AFX*.
Или про замечательные макросы роутинга сообщений. Или "magic" usage, в котором без бутылки не разберёшься.

Кстати а как расшифровывается MFC и VCL?

Насчёт .NET
Вы, уважаемый путаете зелёное с мокрым.
Сравнивать MFC и .NET я бы сказал немножко плохо. Если и сравнивать MFC, то с Windows.Forms (или как его там)

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

А с каких это пор сетевые разработки приоритетная ниша Java?

У меня начинает складываться впечатление, что вы не понимаете, о чём поёте (С) Вадик, сб.СССР

 

[AlexGin]

Пояснения -
для тех "кто в танке":

1) Да ActiveX компоненты (разработанные сторонними компаниями) можно
применять и в проектах на MFC и на VCL и даже в том же .NET. Другое дело -
часто разработчики этих компонентов напрямую ссылаются - что опробовано
с MS технологиями - причем наиболее часто это VB (хотя обычно они удачно
уживутся и с MFC и с .NET). Но применение ActiveX в составе .NET проекта -
ИМХО просто архаично :blink: .
По MFC - я конкретно имел в виду библиотеки классов: BCG, Styngray, Dundas и т. д.

Сравнивать MFC и .NET я бы сказал немножко плохо. Если и сравнивать MFC, то с Windows.Forms

2) Нет, уважаемый, если что-то из набора MFC (Microsoft Foundation Class)
сравнивать с Windows.Forms - это классы CWnd, CWinApp и производные от
них. Не следует забывать, что в MFC есть и работа с БД - ODBC, DAO; и работа
с различными файлами CFile, сокеты также имеются и многое другое.
Просто MFC появилась на 7...8 лет ранее чем .NET - и на сегодня немного устарела,
что не очень мешает ее популярности.
А за .NET - будущее, тут нету спора.

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

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

Подчеркиваю: если я не уверен, то не буду оспаривать и кричать:
истина в последней инстанции,
но то что сам проработал - могу и буду отстаивать...

 

[R-r]

поддерживаю идею с чатом потому как борг ну очень большой для чата и не очень удобный, что касается ичата то проект мертв, а хотелось бы видеть как минимум whiteboard

 

[Accord]

R-r

Интересно. Для чего можно использовать whiteboard?

 

[admin]

Accord

Интересно. Для чего можно использовать whiteboard?

игры в крестики нолики %)

 

[Guest]

Пояснения -
для тех "кто в танке":

Спасибо большое за умение грамотно аргументировать свою точку зрения...

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

Вы, уважаемый, подменяете понятия...
Давайте ещё раз обратимся к сути дискуссии:

Насчет того, что MFC - отличная библиотека классов можно спорить или не спорить. ИМХО
для разработки настольных приложений это вполне справедливо. Такого набора дополнительных библиотек классов и ActiveX компонентов (причем проффесионального уровня) - сложно еще где-то найти...

(выделено мной)
Я не эксперт в лингвистике, но мне показалось, что Вы хотели сказать, что MFC предоставляет большой набор ActiveX компонент. Я не прав?

По MFC - я конкретно имел в виду библиотеки классов: BCG, Styngray, Dundas и т. д.

То есть Вы хотите сказать, что BCG, Styngray, Dundas и т. д. входят в состав MFC?

Далее моё сравнение MFC c Windows.Forms настолько же корректно, как и с VCL(если я не ошибаюсь это расшифровывается как Visual Components Library) со всеми вытекающими последствиями.

Нет, уважаемый, если что-то из набора MFC (Microsoft Foundation Class)
сравнивать с Windows.Forms - это классы CWnd, CWinApp и производные от
них. Не следует забывать, что в MFC есть и работа с БД - ODBC, DAO; и работа
с различными файлами CFile, сокеты также имеются и многое другое.
Просто MFC появилась на 7...8 лет ранее чем .NET - и на сегодня немного устарела,
что не очень мешает ее популярности.

Популярность вешь относительная. У нас например очень популярна группа Руки Вверх и её производные. Надо заметить, что я не считаю что это действительно хорошая музыка.
Моя мысль заключалась в том, что Ваш вывод о том, что MFC хороша основывается на незнании альтернатив.
Я утверждаю что архитектурно MFC отстойна до невозможности. Конкретные прорехи архитектуры я указал выше.

Так всё же. Мне очень жаль, что никто так и не назвал с чем можно сравнить MFC. Может кто-нибудь вспомнить?

 

[Guest_R-r]

whiteboard можно как минимум использовать для быстрого обмена скринами

 

[admin]

Прошу не забывать, что автору нужны не только советчики, но и помошники

 

[Accord]

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

 

[Guest_R-r]

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

 

[Guest]

цікавая прапанова. Я таксама пішу чат, калі дакладней пачынаю і праектую. С++, WTL, ATL, STL, ACE. Хе, ведаеш што такое ACE?
Але па маіх задумках ен павінны быць не толькі дзеля лакальнай сеткі а таксама і дзеля нэту. Выкарысоўваць UDP and TCP. Карацей аптымізаваць. Напрыклад дзеля лакальнай UDP, дзеля нэту TCP. Магчымаць шматузроўневых сэрверых архітэктур, ну і таксама магчымаць бязсэрвернага варыянту. Але ў мяне гэта будзе першы сур'езны вопыт ў напісанні сеткавых аплікацыяў. Вось, зацікавіўся, давай паразмаўляем.
icq: 306955609
msn:
Full e-mail: crusher04@msn.com
nik: crusher