Отправлено Oldring 13 октября 2003 г. 11:03 В ответ на: а потом глюки гребут на протяжении года, постепенно ковыряя этот самый компонент :)))) отправлено Antimouse 13 октября 2003 г. 10:39

• Компонент VB MSComm работает безглючно, но применять его в серьезной коммерческой программе обработки немалого количества данных несерьезно. :) — Antimouse   (13.10.2003 11:18, пустое)
  • Почему? Применяют же VB в серьезных коммерческих программах обработки немалого количества данных? — Oldring   (13.10.2003 11:45, пустое)
    • Ответ -> — Antimouse   (13.10.2003 12:04, пустое, ссылка)
      • Ответ: -> — Oldring   (13.10.2003 12:07, пустое, ссылка)
        • Прежде всего речь идет о всяких компонентах под билдер-дельфи, а ОС и компоненты под бейсик пишут тоже не одни и те же — patton   (13.10.2003 12:12, пустое)
  • а что "серъезно" ? — DASM   (13.10.2003 11:26, пустое)
    • Если серьезно, то надо четко контролировать исходный код. (+) — Antimouse   (13.10.2003 11:57, 188 байт)
      • А по поводу контроля исходного кода - Вы давно в последний раз изучали исходники операционки? — Oldring   (13.10.2003 12:05, пустое)
      • Заблуждение. — Oldring   (13.10.2003 12:03, 147 байт)
        • Так вот и не стоит заблуждаться, очень большие куски данных не всегда "съедобны" (+) — Antimouse   (13.10.2003 12:31, 989 байт)
          • Прочитать буфер один раз на перерисовку экрана - это не долго при любом способе работы с буфером. — Oldring   (13.10.2003 12:47, пустое)
            • А чтобы картинка не дергалась - не прявязывайте скроллирование графика к получению данных. — Oldring   (13.10.2003 12:51, 88 байт)
              • Таймер Windows - жутко непредсказуемая штука, поверьте мне, проверено на практике, специально занимались вопросом плавности вывода графики на экран и пришли к выводу, что лучше, чем привязаться к протоколу ничего нет (именно Com-порт). — Antimouse   (13.10.2003 12:59, пустое)
                • Да бросьте Вы. Есть еще multimedia timer. — Oldring   (13.10.2003 13:15, 501 байт)
                • а может не таймер непредсказуем, а очередь сообщений ? Таймера то в последнюю очередь обрабатываются — DASM   (13.10.2003 13:09, пустое)
                  • именно так. — Antimouse   (13.10.2003 13:53, пустое)
          • вариант - вашу суперзадачу прерывает (ессно, многозадочность ведь) другая не менее суперская прога, (вариант если ваш поток имеет REALTIME приоритет не рассматриваю, тогда б вы были просто засранцем). И вот эта прога делает что-нить умное миллисекунд этак 100-200. И спрашивается - где будут ваши данные ? Пральна, в месте не столь отдаленном — DASM   (13.10.2003 12:35, пустое)
            • Приоритет: NORMAL — Antimouse   (13.10.2003 12:37, пустое)
              • ну вот я и спрашиваю - а если другая задача прерывает ? — DASM   (13.10.2003 12:39, пустое)
                • Возможно будете терять данные (+) — Antimouse   (13.10.2003 12:50, 546 байт)
                  • Если данные теряются - нужно менять программиста. — Oldring   (13.10.2003 12:54, 91 байт)
                    • Не согласен, нужно показать это программисту и пусть разбирается. — Antimouse   (13.10.2003 13:02, пустое)
                      • Об этом программист должен думать головой заранее. — Oldring   (13.10.2003 13:10, 417 байт)
                        • Остается только подобрать программиста. :) — Antimouse   (13.10.2003 13:37, пустое)
                          • О, да, но это ОЧЕНЬ ВАЖНЫЙ этап любого проекта :) — Oldring   (13.10.2003 13:42, пустое)