A circular progress bar control with source, 1 example and chm help file.
(http://i265.photobucket.com/albums/ii214/nwofearless/Asm%20Projects/Circlebar/circlebarexample_zpsecb56b98.png) (http://s265.photobucket.com/user/nwofearless/media/Asm%20Projects/Circlebar/circlebarexample_zpsecb56b98.png.html)
Playing around with gdi+ stuff recently and for some reason i ended up creating this. I had tried to create a version where the center part was completely transparent, (i did get a gdi version to work with transparentblt but that the gdi version did not have any anti-aliasing, and still looked a bit rough when rendering at a higher image size and stretchblt back to smaller size), and cpu usage goes up a bit when moving mouse over the window (higher cpu usage if you have a gaming mouse with higher polling rate probably due to increased wm_mousemove messages). Also you might have to right click, properties, unblock, on the chm for it to show properly. Another thing that bothered me slightly was the way i created the control - still not sure im doing that right :D
Anyhows here it is, maybe someone will find it, or the code useful.
One small issue is that your WndProc does not preserve EBX as required by the WinABI. Otherwise it look goods :icon14:
BTW: WM_NCCREATE is might not be the first message send to a window (AFAICS this is not a problem for your control). For that reason I prefer the method of a wrapper-WndProc that does manage the memory of the window/control-data and pass the pointer through EBX or an additional parameter to the actual procedure. As long as the private data is not allocated, the wrapper call the default window procedure.
Hi fearless,
Looks good. :t
Gunther
Good work Fearless :t
Nice stuff 8)
Biterider
Crashing on winxp SP3
The crash is at CbarGdiDrawDisplayText
in the 1st GdipDrawString here
mov eax, MarkerNo
.IF eax == 0
Invoke GdipDrawString, pGraphics, Addr szWZero, 0ffffffffh, pFont, Addr gdirect, pFormat, pBrush
http://www.jose.it-berater.org/smfforum/index.php?topic=1826.0
http://www.masmforum.com/board/index.php?PHPSESSID=786dd40408172108b65a5a36b09c88c0&topic=11385.0
http://msdn.microsoft.com/en-us/library/windows/desktop/ms534053%28v=vs.85%29.aspx
http://www.wasm.ru/forum/viewtopic.php?id=45877
I copied the circlebarexample1 to my old asus n10 netbook (winxp pro sp3 with an intel atom cpu), and it runs without crashing, altho the desktop and other screens flicker and the cpu goes mad. I can only think it is something to do with the gdiplus version on xp vs win7 x64 maybe. Tbh i never tested it on the netbook before as i hardly ever use it.
I done a search of gdiplus on my netbook and my main pc (win7 x64) and took screenshots of the files listed, altho im not sure it will help at all, but i suppose its a place to start.
(http://i265.photobucket.com/albums/ii214/nwofearless/Asm%20Projects/Circlebar/th_win7x64_gdiplus_zpscb492131.png) (http://s265.photobucket.com/user/nwofearless/media/Asm%20Projects/Circlebar/win7x64_gdiplus_zpscb492131.png.html)
(http://i265.photobucket.com/albums/ii214/nwofearless/Asm%20Projects/Circlebar/th_xpprosp3_gdiplus_zps53ecc07c.png) (http://s265.photobucket.com/user/nwofearless/media/Asm%20Projects/Circlebar/xpprosp3_gdiplus_zps53ecc07c.png.html)
The problem seems to be that pFont is returning 0-1, causing GdipDrawString to crash
It is retrning 0-1, because at GdipCreateFont it returns 2 (which i suppose is an error case), when it should return 0
http://source.winehq.org/WineAPI/GdipCreateFont.html
http://www.news2news.com/vfp/?function=805
Since GdipCreateFont return error on the 1st time it is being used, i presume the error is at the function CbarGdiInit
Might be coz i have specified Segoe UI as the font to use, which according to the wikipedia entry http://en.wikipedia.org/wiki/Segoe is on windows 7 upwards and can be available on winxp if particular software applications are installed. Might have to set it as arial or something and recompile it.
Change these lines in the source:
szDefaultFont db "Segoe UI",0
szWDefaultFont db "S",0,"e",0,"g",0,"o",0,"e",0," ",0,"U",0,"I",0,0,0
Indeed
Changing it to times new roman, worked correctly :)
Very nice example of using gdi+, btw :t
Hi Fearless!!
Perhaps a posible development is an option for isometric or not isometric control.
There is some small issue when control itsn't isometric (and also a white line):
Thanks,
Not sure if I will get a chance to look into it, might look to re-adapt/rewrite it at some point in future. Might just be the angles or sizing of some stuff is slightly off somewhere. Dont think i ever tested it for that kind of shape.
I do remember when creating it I was looking for a solution to 'cut out' the center, so that it would be transparent to what was underneath - probably due to clipping it wouldnt be, so would have to capture background of parent and paint that instead.
I remember thinking about the possibilities of having different shapes for other types of controls, semi-circular and the like (from -90 to 90 degree for example) for other gauges etc. But that was a long time ago.
Also the calculation for figuring out the placement of text around the circle was a bit of a pain from what i remember - probably could be optimized better.
Thanks for letting me know about that issue.
Quote from: fearless on July 25, 2018, 04:44:31 AM
Dont think i ever tested it for that kind of shape.
Automatic resize :biggrin:
(http://www.prodanimal.com.ar/accs/SmallFullApp.jpg)
Graph looks nice, is that a third party control or something you created? Do you have it available as a bundled control? Graph controls are something that has been on my list of things to check into at some point.
Quote from: fearless on July 25, 2018, 06:48:02 AM
Graph looks nice
Thanks. It's under eternal development.
Something more solid is here (http://masm32.com/board/index.php?topic=5244.msg56202#msg56202)
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:
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 :biggrin:
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.
markers string need a little modification:;-------------------------------------------------------------------------------------
; _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.
Nice. Thanks for that.
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 ...
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.
Quote from: fearless on August 23, 2018, 03:55:12 AM
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.
Quote from: Adamanteus on August 23, 2018, 07:20:28 PM
next processor generations
I know, present generations are so confused :biggrin: :biggrin:
My processor don't understand your improvements!
Hi Fearless!
Some little modification solve most of resize problem:
.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).
Hi HSE,
Looks good, nice work.
Compiled it with Radasm, works perfect. Thx. Windows 10 home.