впечатление о 8.02

[volo]

После некоторого тестирования версии 8.02 PBWin, пришел к выводу, что более отточенная была версия 7.02. Правда некоторые моменты исправлены в новой версии - не появляется ошибка переполнения для ASM FPU. Как-то по другому работает "Dialog DoEvents" - в 7.02 обновление диалога после Msgbox работает нормально. в 8.02 какой-то мелкий глюк "не отрисовки". Особо нового по сравнению с 8.01 тоже не увидел. Есть еще несколько моментов, но они не всегда появляются при тестировании 8.02

[keks-n]

Реализации COM интерфейсов там всё равно нет. А вручную их делать весьиа неудобно.

[volo]

продолжение теста:

1. Dialog Redraw в отдельных случаях требует UpdateWindow (не было мороки добавлять)
2. Неадекватное поведение OpenFilesDialog, тоже нужно добавлять дополнительную информацию. (Менял WinAPI на старую версию, все "по барабану")
3. Только что вылезла GPF, что то подобие в виде переполнения (в 7.02 этого не было, произошло при прогонке видео потока, процессор был загружен до 100%. Вылетает где-то на 2-3 сек при 100% загрузке процессора, трудно сказать от чего.

Из плюсов можно заметить какое-то улчшение системы отладки.

[jangle]

volo - где можно скачать версию 8.02???

[keks-n]

Похоже, что он её купил.

[volo]

Похоже, что он её купил.

Первую версию купил в 1996 г., ну и т.д...

8 и последующие версии мне не нравятся из-за неисправленных ошибок.

7.02 версия для меня является найболее надежной.

Вообще - то постоянно тестирующиеся, промежуточные версии - тестируют всего примерно 10 человек.


В 8.00>> версиях добавлено на мой взгляд много ненужного
Например:
#COMPILER PBWIN
#COMPILER PBWIN 8
#COMPILER PBWIN 8.02
#COMPILER PBWIN 8, PBWIN 9
In the first case, compilation with any version of PBWIN would be acceptable. In the second case, compilation with any version of PBWIN 8.xx would be acceptable, while in the third case, compilation with any compiler other than PBWIN 8.02 would generate the compile-time Error 408 ("Wrong compiler for this program").
If the program is compatible with more than one compiler and/or version, multiple parameters may be listed, each separated by a comma. In this case, an error is generated only if there is no match with any of the parameters.


Друзья Боба говорят о достоинствах новой версии (дословно) - "Боб постарел и ему тяжело что-то сделать новое".

Что я ждал от новой версии (вернее что можно было бы добавить)
1. поддержку опкодов PIII-P4 MMX2 и т.д.
2. компиляция OCX модулей или иных плагинов
3. версию для Линукса или для Мак

В принципе поддержку PIII-P4 опкодов можно быстро сделать на основе макросов.

Больших перспектив на будущее этого компилятора я уже не вижу.

[volo]

Продолжение тестирования. Заметил глюк, GPF.
Глюк начал появлятся случайным образом (Ранее замечен небыл)

Ошибка доступа к памяти в процедуре:

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

SUB CLEAR_WINDOW()
    #REGISTER NONE
    LOCAL i      AS LONG
    LOCAL pf     AS LONG
    ! mov OS_CLEAR,1
    updatewindow hwnd
'   ! mov OS_MOROZ,1
    FOR i = 0& TO 63&'127
            ! pushad
            ! mov ecx,OS_X_Y_4
            ! mov pf,0&
            ! shr ecx,2
            ! sub ecx,4&
          loop_c:
                ! mov  eax,LPBIT
                ! mov  edx,pf
                ! mov  ebx,&h04040404
                ! movd mm1,[eax+edx]
                ! movd mm2,ebx
                ! psubusb mm1,mm2
                ! movd [eax+edx],mm1
                ! add pf,4&
                ! loop loop_c
            ! emms
            !popad
        DrawDibDraw DDS,HDC,0&,0&,WINDOW_X,WINDOW_Y,AVS,BYVAL LPBIT,0&,0&,MAXX,MAXY-2&,0&
        updatewindow hwnd
    NEXT i
    POKE$ VARPIX, STRING$(XO*YO*4&-4&, $NUL)
    updatewindow hwnd
    ! mov OS_CLEAR,0&
'    ! mov OS_MOROZ,0
END SUB


[/code]

[volo]

Глюк, который идет с 7 версии

CONTROL ADD IMAGEX...

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

Характерные черты глюка можно увидеть:



разрыв фонового рисунка синего цвета - явно видна полоса разрыва светло-коричневого цвета.

Так же при использовании IMAGEX - некорректно растягивает изображения некоторых размеров. Появляются паразитные светлые пятна линии.

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

[volo]

Глюк указанный выше "разрыв изображения" характерен при выполнении приложения на медленном аппарате.

в P4-3000 глюк не наблюдается
в P3-750 наблюдается.

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


Следующий глюк проявился при портировании проекта с 7 на 8 версии PB
глюк связан с нововедением и исправлением DIALOG NEW:

в PB7 было:
DIALOG NEW hParent&, title$, [x&], [y&], xx&, yy& [, [style&] [, [exstyle&]]] [,] TO hDlg&

в PB8 стало

DIALOG NEW [PIXELS, | UNITS,] hParent, title$, [x&], [y&], xx&, yy& [, [style&] [, [exstyle&]]] [,] TO hDlg

ну и соотвественно появилась "другая реакция"

Проявляется при наличии фонового рисунка на главном DIALOG
и присутствии двух окон CHILD (каждое имеет отдельную CALLBACK). В 7 версии все работает "как часы"
в 8 - фоновый рисунок перекрывает часть одного из CHILD окон, либо закрывает его полностью

т.е. проблема с паразитной прорисовкой фонового рисунка

[jangle]

volo - спасибо за описание глюков 8 версии!

Грустно слышать, что у PB нет будущего, возможно Боб всетаки найдет приемника который будет развивать этот безусловно интересный и необходимый компилятор.
[/img]

[PBDN]

Глюк указанный выше "разрыв изображения"
...
Проявляется при наличии фонового рисунка на главном DIALOG
и присутствии двух окон CHILD (каждое имеет отдельную CALLBACK). В 7 версии все работает "как часы"
в 8 - фоновый рисунок перекрывает часть одного из CHILD окон, либо закрывает его полностью

т.е. проблема с паразитной прорисовкой фонового рисунка

volo,
накидал быстренько сэмпл, чтобы проверить этот глюк, но у меня все нормально прорисовывается, может подправите чтоб глючило ?
проверял на старичке Пень-2 х 300мгц

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

#COMPILE EXE
#DIM ALL
#INCLUDE "WIN32API.INC"
'
%IDD_DLG      =  101
%IDC_TEXTBOX1 = 1001
%IDC_TEXTBOX2 = 1002
$BackgroundBMP="SMTP.bmp" '<- change to yours BMP. I got mine from SMTP example
'
CALLBACK FUNCTION cbTB1()
  STATIC t AS STRING
  '
  FUNCTION=0
  '
  IF CBCTLMSG= %EN_CHANGE THEN
      CONTROL GET TEXT GetParent(CBLPARAM),%IDC_TEXTBOX1 TO t
      t=UCASE$(t)
      CONTROL SET TEXT GetParent(CBLPARAM),%IDC_TEXTBOX2 , t
      FUNCTION=1
  END IF
END FUNCTION
'
CALLBACK FUNCTION cbTB2()
  STATIC t AS STRING
  '
  FUNCTION=0
  '
  IF CBCTLMSG=%EN_CHANGE THEN
      CONTROL GET TEXT GetParent(CBLPARAM),%IDC_TEXTBOX2 TO t
      t=LCASE$(t)
      DIALOG SET TEXT GetParent(CBLPARAM), t
      FUNCTION=1
  END IF
END FUNCTION
'
CALLBACK FUNCTION cbDLGProc()
    STATIC  hBmp    AS LONG
    STATIC  x       AS LONG
    STATIC  y       AS LONG
    STATIC  hBmpDC  AS LONG
    STATIC  hWndSaveFocus AS DWORD
    '
    SELECT CASE AS LONG CBMSG
        CASE %WM_INITDIALOG
            DIALOG GET CLIENT CBHNDL TO x, y
            DIALOG UNITS CBHNDL, x, y TO PIXELS x, y
            hBmp = LoadImage(BYVAL %NULL, $BackgroundBMP, %IMAGE_BITMAP, x, y, %LR_LOADFROMFILE)
        CASE %WM_NCACTIVATE
            IF ISFALSE CBWPARAM THEN
                hWndSaveFocus = GetFocus()
            ELSEIF hWndSaveFocus THEN
                SetFocus(hWndSaveFocus): hWndSaveFocus = 0
            END IF
            '
        CASE %WM_ERASEBKGND
            ' Select the bitmap into a memory DC and transfer it to the dialog
            hBmpDC = CreateCompatibleDC(CBWPARAM)
            SelectObject hBmpDC, hBmp
            BitBlt CBWPARAM, 0, 0, x, y, hBmpDC, 0, 0, %SRCCOPY
            DeleteDC hBmpDC
            '
            FUNCTION = 1
            '
        CASE %WM_DESTROY
            ' The dialog is being destroyed, so release the bitmap handle
            DeleteObject hBmp
    END SELECT
END FUNCTION
'------------------------------------------------------------------------------------
FUNCTION PBMAIN()
    LOCAL hDlg  AS DWORD
    '
    DIALOG NEW  %HWND_DESKTOP, "DLG", 123, 73, 192, 78, %WS_POPUP OR %WS_BORDER OR _
        %WS_DLGFRAME OR %WS_CAPTION OR %WS_SYSMENU OR %WS_MINIMIZEBOX OR _
        %WS_CLIPSIBLINGS OR %WS_VISIBLE OR %DS_MODALFRAME OR %DS_CENTER OR _
        %DS_3DLOOK OR %DS_NOFAILCREATE OR %DS_SETFONT, %WS_EX_WINDOWEDGE OR _
        %WS_EX_CONTROLPARENT OR %WS_EX_LEFT OR %WS_EX_LTRREADING OR _
        %WS_EX_RIGHTSCROLLBAR, TO hDlg
    CONTROL ADD TEXTBOX, hDlg, %IDC_TEXTBOX1, "TextBox1", 20,  8, 64, 24, CALL cbTB1
    CONTROL ADD TEXTBOX, hDlg, %IDC_TEXTBOX2, "TextBox2", 96, 32, 60, 24, CALL cbTB2
    '
    DIALOG SHOW MODAL hDlg, CALL cbDLGProc
END FUNCTION
'     


[volo]

volo - спасибо за описание глюков 8 версии!

Грустно слышать, что у PB нет будущего, возможно Боб всетаки найдет приемника который будет развивать этот безусловно интересный и необходимый компилятор.
[/img]

PB запатентован, врядли Боб передаст свой патент "приемнику".
На мой взгляд появилась тенденция - после пика PB в конце 98 и до 2002 (времена популярности PII, MMX), постепенно опытные разработчики начали переходить с PB на некоторые другие компиляторы. Явное подтверждение - всего 1 вакансия "PB программиста" на Dice.

Для меня прослеживаются проблемы:
1.Отсутствие поддержки клиентской части для интернета (банальная компляция OCX).
2.Не поддерживает LIB
3.отсутствие поддержки ООП, но это дело вкуса
4.остутствует поддержка либо Линукса либо Мак'а, нет возможности программировать "микрокомпьютеры" с WinCE (это я обощенно говорю)
5. Самое главное для меня, отсутствие поддержки P3-P4 опкодов.
Получается вручную сам мастыришь либо МАCRO либо еще чего.
6. Необходим конвертер либо прямое использование С-заголовочных файлов микрософта для PB

Самое первое негативное впечатление у меня вызвал один из продуктов в 90-х годах, если кто помнит был PBDK-2.5. (интерфейсная библиотека работы из ДОСа в Windows. Если мне память не изменяет, то купил ее я за 25$. Документация - "никакая", полуглючная. Работа библиотеки такая же.

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

[volo]

Глюк указанный выше "разрыв изображения"
...
Проявляется при наличии фонового рисунка на главном DIALOG
и присутствии двух окон CHILD (каждое имеет отдельную CALLBACK). В 7 версии все работает "как часы"
в 8 - фоновый рисунок перекрывает часть одного из CHILD окон, либо закрывает его полностью

т.е. проблема с паразитной прорисовкой фонового рисунка

volo,
накидал быстренько сэмпл, чтобы проверить этот глюк, но у меня все нормально прорисовывается, может подправите чтоб глючило ?
проверял на старичке Пень-2 х 300мгц

Ваш пример у меня работает нормально.

Глюк возникает при использовании
1. рисунок в ресурсах

http://sp.ltr32.com/test/skine.bmp

2. Растяжка этого рисунка на 1024х750 диалоговое окно (типа фона)

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

первоначальная загрузка
DIALOG NEW hdlgy, $TITLEN,,,534&,325&,%DS_3DLOOK OR %WS_POPUPWINDOW OR %WS_BORDER TO hDlgM

CONTROL ADD IMAGEX,      hdlgM,%ID_SKINE,"skine" & FORMAT$(parameters.expo_color),0&,0&,0&,0&',%WS_DISABLED
....
обработка событий

....
обработка событий

getwindowrect GetDesktopWindow, re
OS_MAXX = re.nright
OS_MAXY = OS_MAXX * 0.75!  '666!
SetWindowRgn hDlgM, %NULL, %TRUE
MoveWindow hdlgM, 0&, 0&,OS_MAXX,OS_MAXY,%TRUE     '38

....
обработка событий
DIALOG   GET SIZE  hdlgM TO x1,y1
CONTROL SET SIZE  hdlgM, %ID_SKINE, x1,y1
...
обработка событий (перенос и прорисовка других элементов)

**** МОМЕНТ ГЛЮКА НЕПРОРИСОВКИ. рисунок глюка см. в этой ветке форума выше.



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

Наблюдал другое характерное проявление глюка - в первом случае
не прорисовывался прямоугольник и появлялись паразитные светлые
синие пятна-линии
http://sp.ltr32.com/test/1.bmp
, во втором случае непрорисовывался прямоугольник, но низ был как
бы побит "дождем" - точками. Это не глюк ASM, проявляется реже.

[PBDN]

видимо нить не успевает отработать
закрашивание области, как параллельно начинается прорисовка
элементов диалога

Одназначно могу сказать мне до Вас о-о-о-чень далеко в
работе с графикой, но на всякий случай поделюсь.
(сорри заранее если Вам это уже известно)
Была у меня задачка, паралельно следить за одним специфическим
аппартным интерфейсом(custom design + довольно короткий ,но скоростной поток)
и одновременно отображать графически данные основаные на полученной информации.
Отображение графика я тоже пытался сделать из отдельного трида, глюки приблизительно
очень похожие на то что Вы описывали. Пытался грешить на ПБ, но потом
сделали тестовые програмки на С, дельфи, и фасме. Результат оказался то-же.
Где то в дебрях вечно меняющихся ссылок МСДНа мы тогда нашли рекомендацию,
что все что выводиться на экран, надо делать из основного трида. Помогло.
Каким то образом винда всегда оставлет наибольший приоритет работы с экраном именно основном триду,
т.е. триду в котором родился основной диалог.
Пробовали вручную повысить приоритет у других тридов, но толку - ноль.
Т.е. мы реализовали тогда всю математику в отдельном триде, а команды
рисования(вывод текста...), посылали через сообщения в главный трид.
Только так удалось уйти от проблемы.

т.е. схема приблизительно такая

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

%WM_Private_SetText =%WM_USER+7500
%WM_Private_DrawLine =%WM_USER+7501
...
...

в CALLBACKе основного диалога обработка приватных сообщений

   CASE %WM_Private_SetText
       LOCAL lpsz as ASCIIZ PTR
       lpsz=CBWPARAM
       CONTROL SET TEXT CBHNDL, LOWRD(CBLPARAM), @lpsz


а из математического трида просто посылали сообщения на отображение информации(рисования)
в зависимости от нужности

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

SendMessage[PostMessage](hDlg,%WM_Private_SetText,ByVal VARPTR(sString),MAK(DWORD, %IDC_TextBox01, 0)  )


Можно еще подтормаживать основной трид через SleepEx и запихивать в очередь APC основного трида
напичканые данными функции для шустрого отображения на экране.
Но все от задач конечно зависит.

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

Т.е. что хотел сказать - все что работает с экраном - только из основного трида.

Еще раз сорри если говорю давно известные вещи, и спасибо за шикарные примеры !

[Dark Machine]

Вышел патч. Версия 8.03.0040
Список исправлений/Новшеств

- Increased the speed and reduced the CPU usage of a GRAPHIC WINDOW

- Improved the LCASE$, MCASE$, and UCASE$ statements by adding an optional parameter
to specify whether to use the Console's OEM charset or the systems ANSI charset when
converting a string expression to another case. If the charset parameter is not used
the PowerBASIC Console Compiler defaults to using the Console's current OEM charset.

- DIALOG DOEVENTS now has an optional sleep& parameter to specify the number of
milliseconds that the current thread will be paused, allowing other processes
(or threads) to continue. If the sleep& parameter is not specified then the
current thread will be paused for 1 millisecond.

- Resolved an issue DISKFREE and DISKSIZE returning 0 when a null string parameter
was used.

- Fixed an issue with GOTO DWORD in a single-line IF/THEN.

- CONTROL REDRAW and DIALOG REDRAW now execute the window update immediately.

- Incorrect positioning of a dialog using DIALOG NEW PIXELS when specifying a parent
dialog handle not being relative to the parent dialog has been corrected.

- An issue with DIALOG NEW PIXELS executing %ds_absalign, %ds_center, and %ws_child
incorrectly has been resolved.

- DIALOG SHOW MODELESS now displays the dialog immediately in all cases.

- Corrected an issue with DIALOG NEW PIXELS not expanding the dialog's width to
accommodate a caption.

- Resolved an issue where creating a dialog with DIALOG NEW PIXELS that is larger
Than the desktop and that uses the %DS_CENTER style may not of been visibly displayed.

[volo]

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

Т.е. что хотел сказать - все что работает с экраном - только из основного трида.

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

Да, в принципе этот глюк - долгожитель. Поделюсь, когда увидел его проявление в первый раз:

тогда еще был аппарат K6-2-500,
Cистема читала в параллельном режиме 7 файлов большого размера (не по сети).
Т.е. сразу работает 7 нитей, открыто 7 файлов, и читается 7 потоков.
Ресурс времени примерно равнозначно разделен на все процессы.
На диалоговом окне находится около 30-40 кнопок запускающих чтение тех или иных файлов как нитей. Так вот при одновременном чтении 7 файлов, при обновлении диалога - пропадала та или иная кнопка. Просто тупо исчезала и больше не появлялась. Я писал в PB, но они не поверили в наличие этого эффекта. Деффект явно проявлялся как неотрисовка из-за нехватки ресурса (времени, процессора или чего-то еще). При переходе на более мощный аппарат, эффект пропадания кнопки почти исчез.