Circlebar Control

[Adamanteus]

 Very good, and thanks - even for non-commercial projects !
But on my Windows 8, the precompiled program works well, but when I builded it, the lower break of the circlebar becamed upper, and now I'm using -114.0 and -314.0 angle constatnts, so it looks like meanwhile it work changing viewport, but GDI function nothing changing - so, looks like unwaitly some GDI+ transforms  apply  :exclaim:

[HSE]

The problem is not the shape because the example with a dialog work perfectly. Perhaps something related with scale in dialogs.

Fearless, you forget to allow resizing. Processing WM_SIZE solved the problem... and create others

[fearless]

Nice one, thanks for letting me know. Glad to hear its all working.
Edit: Ah yeh, I see the angles and stuff for the text and markers prob needs recalc as well, probably from the resize as well.

[HSE]

markers string need a little modification:

Code Select Expand

;-------------------------------------------------------------------------------------
; _CalcXYFromAngle - Gets sin and cos of angle specified and returns as x and y coords
;
; xpos = r * cos(theta)
; ypos = r * sin(theta)
;-------------------------------------------------------------------------------------
_CalcXYFromAngle PROC PRIVATE USES EBX hCbarControl:DWORD, angle:REAL4, xpos:DWORD, ypos:DWORD
    LOCAL pCbarData:DWORD
    LOCAL ProgressWidth:DWORD
    LOCAL rect:RECT
    LOCAL WinHt:DWORD, WinWd:DWORD
    LOCAL ClientY:DWORD, ClientX:dword

    Invoke _GetCbarDataPtr, hCbarControl
    mov pCbarData, eax
    mov ebx, pCbarData
    mov eax, [ebx].CBAR_DATA.ProgressWidth
    mov ProgressWidth, eax; 20d
    mov eax, ProgressWidth
    shl eax, 1
    add eax, 16d
    ;sub eax, 10d
    ;add eax, ProgressWidth ;, 8d
    ;add eax, ProgressWidth
    mov ProgressWidth, eax
   
    Invoke GetClientRect, hCbarControl, Addr rect
    sub rect.right, 2d
    sub rect.bottom, 2d   
   
    mov eax, rect.bottom
    sub eax, ProgressWidth
    mov ClientY, eax

    mov eax, rect.right
    sub eax, ProgressWidth
    mov ClientX, eax

    finit
    fld angle
    fld rads
    fdiv
    fldpi
    fmul
    fcos

    mov eax, ClientX
    shr eax, 1
    mov WinWd, eax

    fild WinWd
    fmul
    fld someval
    fmul
    fild WinWd
    fadd
    fistp WinWd

    mov eax, WinWd
    ;sub eax, 1   
    mov ebx, dword ptr [xpos]
    mov [ebx], eax
   
    fld angle
    fld rads
    fdiv
    fldpi
    fmul
    fsin
   
    mov eax, ClientY
    shr eax, 1
    mov WinHt, eax

    fild WinHt
    fmul
    fld someval
    fmul
    fild WinHt
    fadd
    fistp WinHt

    mov eax, WinHt
    ;sub eax, 5   
    mov ebx, dword ptr [ypos]
    mov [ebx], eax   
   
    ret

_CalcXYFromAngle endp


If control is a perfect circle then result is exactly that of original.

[fearless]

Nice. Thanks for that.

[Adamanteus]

Attached version of CirclebarControlAll with small improvements for Unicode support.
But ... Meanwhile, I added good style library stuff to code and all types that was unused and is include files, even more (so, that to build TEXTEQU's maybe need to add).
So, that's example what happening with you code after, this work could make tie - and I'm thinking that from it, is need to make followings ...

[fearless]

Thanks, looks good. I also now see what you meant about aligning - i was only doing it at start of .code. Didnt think to do it at the start of each function. I think i will add this in to the ModernUI stuff. Cheers.

[Adamanteus]

Didnt think to do it at the start of each function. I think i will add this in to the ModernUI stuff. Cheers.

Basically aligning mought do linker, but inside module – could only to do assembler, so need directives. That to fall all this work to linker is need more smaller segments - for it library code dividing on function per module ...
In program, function calls passing to near code, that successfully loading by cache, bat when calls missing cached memory, it could pass to not cached address, as used first procedure instructions, if that wasn't aligned.
Align need to next processor generations, that could be 128 bit – so 16 bytes.

[HSE]

next processor generations

I know, present generations are so confused 

My processor don't understand your improvements!

[HSE]

Hi Fearless!

Some little modification solve most of resize problem:

Code Select Expand


    .elseif eax == WM_SIZE

        Invoke _GetCbarDataPtr, hWin
        mov pCbarData, eax   
  mov ebx, eax
   
mov eax, [ebx].CBAR_DATA.hBaseBmp
.IF eax != NULL
        Invoke GdipDisposeImage, eax
.ENDIF
mov ebx, pCbarData
        mov eax, [ebx].CBAR_DATA.BaseColor
        Invoke CbarGdiCreateBaseBitmap, hWin, eax
mov ebx, pCbarData
        mov [ebx].CBAR_DATA.hBaseBmp, eax
       
       
mov ebx, pCbarData
mov eax, [ebx].CBAR_DATA.hCircleBmp
.IF eax != NULL
        Invoke GdipDisposeImage, eax
.ENDIF
mov ebx, pCbarData
        mov eax, [ebx].CBAR_DATA.CircleColor
        Invoke CbarGdiCreateCenterBitmap, hWin, eax
mov ebx, pCbarData
        mov [ebx].CBAR_DATA.hCircleBmp, eax

mov ebx, pCbarData
mov eax, [ebx].CBAR_DATA.hMarkerTextBmp
.IF eax != NULL
        Invoke GdipDisposeImage, eax
.ENDIF
        Invoke CbarGdiCreateDisplayTextBitmap, hWin
mov ebx, pCbarData
        mov [ebx].CBAR_DATA.hMarkerTextBmp, eax


   if 0
mov eax, [ebx].CBAR_DATA.hProgressBmp
    .IF eax != NULL
        Invoke GdipDisposeImage, eax
    .ENDIF

        Invoke CbarGdiCreateProgressBitmap, hWin, BrushColor, wParam ;Percent
        mov ebx, pCbarData
        mov [ebx].CBAR_DATA.hProgressBmp, eax ; save new bitmap handle

   endif

    mov eax, 0
    ret

I commented ProgressBmp replacement because requiere something else to redraw progress (a postmessage perhaps).

[fearless]

Hi HSE,

Looks good, nice work.

[BugCatcher]

Compiled it with Radasm, works perfect. Thx. Windows 10 home.