Конференция VBStreets

Понадобился один старый исходник по DirectShow, забирающий кадры из потока, на 9 работал нормально, на 9 под новые API 119 тоже нормально. С 10.02 да и тоже самое с 10.03 появились "затыки" с полным подвисанием процесса - подвисание приложения, затыкание процесса происходило не сразу, судя по всему проблемы связаны с новой реализацией обработкой ТHREAD процедур, и возможно новой реализацией DIALOG DOEVENTS. Еще как-то странно на подвисание действует #STACK (это все для 10-ки). Решить проблему с подвисанием для 10-ки удалось с заменой в отдельных местах DIALOG DOEVENTS на SLEEP (или добавлением), увеличение значений последних, и использование #STACK "с размером по умолчанию". Но не уверен что данная проблема не вылезет через некоторое время на 10. Жаль убитого времени просто. С 9-кой все работает как часы.

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

Да, обидно что у тебя так выходит. У меня таких проб. пока нет. Может быть заменить DIALOG DOEVENTS на АПИ команды?

DarkMachine писал(а):Да, обидно что у тебя так выходит. У меня таких проб. пока нет. Может быть заменить DIALOG DOEVENTS на АПИ команды?

Думаю проблема пошла от изменения реализации SUB и FUNCTION, путем добавления THREADSAFE и другого в 10 версии.
Я вначале пытался использовать новую FASTPROC для отдельных моментов, скорость особо не возросла. "Затыка" появляется когда идет обращение параллельно к процедуре считывания кадра, - видимо где-то в 10-ке не хватает временной задержки при обращении. Или может быть стек процедуры или функции не успевает очистится. Причем например 5-10 таких обращений проходит нормально, а потом полный подвис (это на 7-ке). Такая - неприятная, не сразу появляющаяся ошибка. В 9-ке работает все очень хорошо. Понимаю - возможно еще может быть глюк кодека при параллельном обращении в 10 ке, но в 9 -ке все нормально.

Еще заметил при разных вариантах #STACK > 1MB выскакивают различные варианты ошибок типа С0000005 и др., видимо что-то не успевает, и пытается писать в несуществующую память.

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

jangle писал(а):Похоже 10 версию делала другая команда разработчиков, нежели предыдущие версии.

Скорее всего да. Вот еще один небольшой прикол, кто не знает, - может убить при отладке некоторое время, это для 10 ки,

65535 это эквивалент 0xFFFF или &hFFFF

Код: Выделить всё

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG

    ? STR$( 1/65535) & $CR & STR$( 1/65535&) & $CR & STR$(1/&hFFFF) & $CR & STR$(1/&HFFFF&)

END FUNCTION
               


результат:
1.52590218966964E-5
1.52590218966964E-5
-1
1.52590218966964E-5

Сказал бы ещё, что было до десятки... Интересно ведь

Да, каким боком -1 получилось вообще непонятно.

ger_kar писал(а):Да, каким боком -1 получилось вообще непонятно.

Делится 1 на int16 со значением -1

Qwertiy писал(а):Сказал бы ещё, что было до десятки... Интересно ведь

в продолжение об проблемах и методах их обхода в версии 10. Версии 7-8-9 данных проблем не имеют.
диагностика таких глюков может занять много времени. Вот ниже кратко:

1. для 10.00 10.02 и 10.03 ранее уже описывалась проблема с мертвым зависанием, чаще всего она возникает при вызове из основного Callback Modal - вызова или создания какого нибудь окна - чаще всего например окна выбора файла для загрузки или сохранения. Возникает на 3, 4...N раз.
Нестабильное появление. Скорее всего возникает при переполнении внутреннего стека, и глюком dialog-doevents.

Решение - использовать для вызова\создания доп. диалогов типа "Сохранить как" из callback функции - Thread Create

2. Верс. 10 - при вводе русского текста в TextBox (на ХP работает нормально) в некоторых версиях WIn7 печатаются "кракозяблы", англ. текст - нормально
глюк - юникода, при копировании русского текста все нормально.

Решение добавить #OPTION ANSI

3. Для версии 10.02 глюк возникает с жестким GPF при вызове (глюк на Win7 проявился, на Хр не тестировал)
MENU SET TEXT hMenu, BYCMD position&, txt$

глюк связан видимо с введением юникода поумолчанию
глюк проявляется при установленной опции #OPTION ANSI

Решение - убрать #OPTION ANSI

4. Глюк в принципе с проявлениями во все версиях #С0000005 и подобные, GPF появляется при загрузке или сохранении изображений больших размеров при использовании GDI+. Например размер 7130х4912 pix. То что поменьше работает без проблем. Проявляется нестабильно. Возможно связано со стеком.

5. Были еще глюки с FastProc, разбираться детально времени не было - проблема решилась заменой Fastproc на SUB, как и было в 9 версии (глюк касался в основном ASM кода)

После пере компиляции довольно большой программы из 9.05 в 10 версию обнаружил что в десятке она работает неправильно.
Где-то в 10 компиляторе есть баги.
Причем баги самые мерзкие. Там много вычислений. В 10 версии программа выдает неверные математические результаты!
Уже из-за этого на этой версии можно ставить крест.

jangle писал(а):Причем баги самые мерзкие. Там много вычислений. В 10 версии программа выдает неверные математические результаты!

А какого характера вычисления? Арифметические или может функции какие то неправильно рассчитывает?

ger_kar писал(а):А какого характера вычисления? Арифметические или может функции какие то неправильно рассчитывает?

Пока разбираюсь, в программе очень много кода. Видимо придется одновременно отлаживаться в 9 и 10 версии, чтобы сравнивать результаты работы.
Позже напишу о результатах.

Продебажил код. Выяснилось, что дело не в математике. А в функции:

Код: Выделить всё

Graphic Get Client To X, Y

В 10 версии она возвращает X=0, Y=0. Поэтому графики на форме рисуются неправильно.
В 9 версии возвращаются правильные целые значения.

jangle писал(а):В 10 версии она возвращает X=0, Y=0

Т.е. всегда возвращает? А конкретно в какой версии проверялось в 10.4? Интересно другие десяточные версии имеют этот баг.

Разобрался с проблемой. В 10 версии меняем

Код: Выделить всё

Graphic Get Client

на

Код: Выделить всё

Graphic Get Canvas To

И все заработает правильно. Потому, что в 10 версии в очередной раз поменяли язык:

GRAPHIC GET CLIENT statement now returns the client area size in dialog units or pixels only. The size represents the physical size of the display area on the screen. This change was necessary because of the improved graphic functionality involving virtual windows, resizing of graphic windows, etc. Prior versions returned scaled sizes if a GRAPHIC SCALE was executed. Substitute GRAPHIC GET CANVAS for functionality which is fully compatible with the old format.

Ох уж эти любители все менять. Что-б их...

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

Код: Выделить всё

Graphic Get Client

в 9 и 10 версиях работает по-разному

Сорри за оффтоп, я тут вспомнил, как Хакер про объявление As New в VB.NET возмущался, а там всё-таки разные языки были