OK....succeeded to make a custom progressbar control in replacement of msctls_progress32 using HCBT_CREATEWND
Many tks for drizz for the custom control functions.
I just finished analyzing the way progressbar works exactly inside comctls32.dll (finished v 5 and started analysis on v 6 that uses visual style stuff)...I´ll later update this custom control to work exactly as the ones existent inside comctls (But....adding more progressbar messages and styles). It will then use the windows messages and the ones that were customized.
Once this is finished it would be a good idea do the same for the other windows controls as well.
(http://www.freeimagehosting.net/t/jjvci.jpg) (http://www.freeimagehosting.net/jjvci)
Source code is embeded in the app. RosAsm source code.
This is just a beta test version. I´ll try to finish it as soon as possible.
The main function is CustomDlgProgressBar
Also created a GetWindowPos (http://masmforum.com/~masm32/board/index.php?topic=28.0)
Updated test version - now it can display a border as the background (it ressembled 3d)
Fixed test version
(http://www.freeimagehosting.net/t/mvey8.jpg) (http://www.freeimagehosting.net/mvey8)
OK...now enable it to runs vertical and smooth
new version.....added borders surrounding the progressbar and enabled vertical in default win style and allowed change the amount of blocks on it.
(http://www.freeimagehosting.net/t/qhfq6.jpg) (http://www.freeimagehosting.net/qhfq6)
Some pretty good examples guga. thx
Hi xandax. Many tks.
I´m clkeaning up the code and will try to fix some minor problems i found.
Later i´ll also try to make it work the PBM_SETSTATE, PBM_GETSTATE, PBM_SETMARQUEE messages with and without visual styles.
Once i succeed to reproduce all common windows messages from Vista/Seven to work on winXP and earlier, i´ll try to ad some more effects on the progressbar (enabling a background image, shrinking the text along the progressbar movement etc).
All of this will work on simple sendmessages commands
i would like to see the source.... are you going to post that?
I did not removed the source.
The source code is already inside the file. The app is made with RosAsm software, which means it contains the source embeded in the executable. To you see the source you need to open it in RosAsm.
You need to dl rosasm pack on my forum under "RosAsm Development" . After you dl complete pack, all you need is to dl the update.
There is no need to install...Only unzip and run the main executable. ON this release probably you won´t need to configure the settings, since i already did that....But if you need, it is easy to follow.
The last official version is RosAsm2053a on the updates.
Once i finish the progressbar control...i´ll restart updating rosasm itself (i´m building a new feature for the debugger)
To open and run this customized Progress bar demo, all you need to do is open it in rosasm:
1 - Pressing F5 key assembles the App (Or use the "Compile" item on the main menu)
2 - Pressing F6 key it assembles and runs the app through rosasm debugger. (The debugger is a source code level) (or use "Run" item on the menu...but....to run...you need to assemble it 1st)
If you want to kiil (delete) the source that is embeded you need the app sourcekiller made for it. Not sure if i included in the pack....but if i didn´t...i´ll include it later)
P.S.: If you have troubles, tell me so i can help.
Sorry if i didn´t made the masm source. It have being a long time since i last coded in masm. So, for me it is faster coding in RosAsm. RosAsm syntax is easy and the macro set is similar to the masm ones (err...more likely it is Nasm based) . I have in my plans to make a converter to RosAsm to Masm/Fasm/Nasm syntaxes and vice-versa, but....i´ll only reach that after i succeed to make rosasm import and export libraries, and several other updates i have in mind.
Thanks guga. Nice work. I'll download
guga,
What method do you recommend for extracting the source code from your executables. I won't install RosAsm just to get the source. Surely there is a better way. Edit with NotePad?
I appreciate your effort and hope to learn from your code!
Thanks in advance,
farrier
All you need is open it with RosAsm (there´s no need to install, just unzip it). Open the executable in rosasm and on the menu you choose:
"File+Save Source Only"
But, i´m uploading the source here on the version i´m working on if you want to take a look.
This is only the asm source. The dialog is not included, since it is a binary data and not a rsrc one.
The source is divided in titles internally (A TITLE is a token that makes RosAsm to display the source in each Tab)
When you open the source in notepad you will see 1st my macro set. The next TITLE is called " Part01" that is responsable for the GUI only.
The main function responsable for the customized progressbar itself is CustomDlgProgressBar (Inside TITLE "Customized")
This is the main function that hooks the default win progressbar and recreates the functions and messages. The function "CbtHookProc" is responsable for that as the label suggests.
The main progressbar function starts at: CPB_WndProc and is something like:
Proc CPB_WndProc:
Arguments @hWnd, @uMsg, @wParam, @lParam
xor ebx ebx
call 'USER32.GetWindowLongA' D@hWnd, 0
mov ecx D@uMsg
mov edx D@lParam
mov esi eax
.If_Or D@uMsg = &WM_PAINT, D@uMsg = &WM_PRINTCLIENT
call CPB_OnPaint esi, D@hWnd, D@wParam
;call ProPaint esi, D@hWnd, D@wParam
xor eax eax
(...)
.Else_If D@uMsg = &PBM_SETMARQUEE
.Else_If D@uMsg = &PBM_SETSTATE ; &PBST_NORMAL, &PBST_ERROR, &PBST_PAUSED
.Else_If D@uMSg = &PBM_GETSTATE
.Else
@Default:
call 'USER32.DefWindowProcA' D@hWnd, D@uMsg, D@wParam, D@lParam
.End_If
EndP
I recommend you open it in RosAsm to you be able to go back and forward inside the code using the mouse click button on a given label (variable, functions etc)....This way would be easier for you to follow the code, i think.
But, if you want to try using notepad only...No problem...but it will take more time i guess. Also, if you want, i can split the different titles and upload here. (Think on Each title as a different asm file)
If you need any help, let me know.
I´m still working on the code. So i didn´t botter cleaning it yet. I´m trying to make the text shows vertically and make it goes back and forward accordying to the movements of the progressbar. I`m analysin g a MFC code of a app called ProgressCtrlX_demo for this purpose.
This is a test that maked the text vertical (not the font, just the text pos)....and allows it to be multiline
; PBCreateFont
; http://www.swissdelphicenter.ch/torry/showcode.php?id=506
Proc WritePercentage:
Arguments @hMem, @pRect, @nPct
Local @hOldFont, @TextLen
Structure @StrBuff 64, @StrBuff_DataDis 0
Uses edi, eax, ecx, edx
mov edi D@hMem
mov esi D@pRect
call ZeroMemory TextRect, Size_Of_RECT
move D$TextRect.Left D$esi+RECT.LeftDis
move D$TextRect.top D$esi+RECT.TopDis
move D$TextRect.bottom D$esi+RECT.BottomDis ; height
move D$TextRect.right D$esi+RECT.RightDis ; width
call 'USER32.GetClientRect' D$edi+PRO_DATA.hwndDis, textrect2
;call ZeroMemory D@StrBuff, 64
call 'GDI32.SetBkMode' D$edi+PRO_DATA.hMemDCDis, &TRANSPARENT
call 'GDI32.SelectObject' D$edi+PRO_DATA.hMemDCDis, D$edi+PRO_DATA.hFontDis
mov D@hOldFont eax
C_call 'USER32.wsprintfA' D@StrBuff, {B$ "%d%%
456", 0}, D@nPct
call StrLenProc D@StrBuff
mov D@TextLen eax
mov ecx &DT_VCENTER__&DT_NOCLIP__&DT_SINGLELINE__&DT_CENTER
Test_If D$edi+PRO_DATA.dwStyleDis &PBS_VERTICAl
; get height of text with word break (no text drawing occurs here)
call 'USER32.DrawTextA' D$edi+PRO_DATA.hMemDCDis, D@StrBuff, eax, TextRect, &DT_CALCRECT__&DT_WORDBREAK__&DT_CENTER
; Set new positions so text will be vertically centered
;mov D$TextRect.Left 0
mov eax D$textrect2.bottom
shr eax 1
mov ecx D$TextRect.bottom
shr ecx 1
sub eax ecx
mov D$TextRect2.top ecx
;move D$TextRect.bottom D$esi+RECT.BottomDis
mov ecx &DT_WORDBREAK__&DT_CENTER
mov D@TextLen 0-1
Test_End
call 'USER32.DrawTextA' D$edi+PRO_DATA.hMemDCDis, D@StrBuff, D@TextLen, TextRect2, ecx;
call 'GDI32.SelectObject' D$edi+PRO_DATA.hMemDCDis, D@hOldFont
EndP
guga,
Thanks for the code.
Notepad it is! I have a mental block against RosAsm, maybe I'll get over it!
Do I understand that dialog code would not be included in a RosAsm program? Only the digital data required for the .exe to display the graphics?
Thanks,
farrier
Hi farrier
No worry. You ´ll get over it soon :t
Quote
Do I understand that dialog code would not be included in a RosAsm program? Only the digital data required for the .exe to display the graphics?
No...dialog is included in RosAsm. But, so far it is created with RosAsm itself internally (under rosasm resource editor), using CreateDialogIndirectParam. The dialogs are mapped from DLGTEMPLATE internally. I mean it don´t parse any rsrc file. The user creates his resources from RosAsm resources editor. So far, it can export/import a text and binary representation of the resources (bin or text DLGTEMPLATE data)
I´m working on a resource editor to alow parsing rsrc, res, dfm files as well (probably VB resources too, using a proper converter for VB files). Once i finish this new upgrade, RosAsm will be able to import and export rsrc/res/dfm or other types of resources files. (I plan to allow converting also from 16bit resources - I know, too old...But...i would like to see the resources inside the 16bit dlls inside winXP as well).
There are several updates i plan for RosAsm, but, now..i´m working almost alone (JE made good upgrades too, that i´l take a look after i upgrade some tools for the debugger)...But since i´m working pratically alone it will take a long time for me to implement all updates i have in mind like:
* New resources editor:
- New GUI editor for teh resource (I like the looks of visual studio resource editor. i`ll try to make it more similar to it)
- It will allow parsing and exporting rsrc, res and other resource files.
- It will create full windows apps (their skeletons at least) based on the resources
- Allow the edition of all windows resources types
- Allow exporting resource obj files
* Disassembler:
- Update some internall functions
- FInish the DIS system (Data identifying system). A sort of a digital DNA to identify functions based on teh original libraries
- Enable ability to import and export pdb, dbg files
* LibScanner
- Finish the libscanner enabling it to import and export all kind of lib files to create the proper DNA (DIS) data files for usage on the disassembler
* Debugger
- Finish the ability to dump and fix the loaded modules on user choice
- Make a dialog to display properly the disasembled files while you are debuggin. (Now it display only a single line on the debugger caption)
- Try to make a real time log file to the user analysis the different flags of the code flow that is being debugged
* General upgrade
- Separate the assembler, disasembler, debugger, resources editor and make they works standalone or integrated with the whole RosAsm pack. (Isolating the different parts of the project is good for a matter of development)
- Enable the hability to users create plugins for RosAsm
- Enable the hability to users import and export lib/obj files in RosAsm
- Perhaps i´ll enable the hability to import and export linux elf files (For usage under wine)
- Enable a light script engine for the disassembler structures, equates etc
As you see, i have lots of projects planned, but working quite alone is a hard task to accomplish soon. So, new developers are welcome to help
New from progressbar
I´m on the way to succeed to make the progressbar existant in windows7 works on windowsxp and windows 2000 (and perhaps, also on win95). Once i finish, i would like to ask you guys that have windows7 to test this please.
One of the flags i understood how to enable is : PBST_PAUSED
One question only.
There is a internal function inside comctl32 from windows7 that is called Progress_SetAnimateTimer. Inside this function there is a call to SHWindowsPolicy (in shell32.dll) with the flag POLID_TurnOffSPIAnimations. This function is supposedlly needed to increase the animation time of the Progressbar by temporarilly disabling the other animations in windows (such as cursors etc) while the progressbar is running.
Unfortunatelly, SHWindowsPolicy exists only on vista and above. So i wonder if it is really necessary to disable other animations on windows to make the progressbar runs faster. There is a workaround on winxp that forces the registry to disable the animations (don´t know if a reboot is necessary)...but...on the current machines available in market (Mine for example is a I-7) is it really necessary to disable other animations ????
I´m not quite sure if disabling animation is really a must, because inside comctl32.dll (on win7) it seems to me that it is only a matter of bad coding style inside the dll that makes the progressbar runs slowly. Internally it have tons of "spaghetti" style and framed jmps/calls, and what seems to be some stack problems that probably once fixed makes it runs faster.
Also....is there a way to make a app works with visualstyles without embeding the xml in the resources section ? (i mean, i would like to enable visual styles using a xml file existent in the same directory of the main app. Specially a xml that enables the progressbar behaviour with visual styles. Without calling the comctl32.dll in winsxs directory, of course, because it must uses the routine i made that interceps the progressbar itself). For example, is there a function that can be called in uxtheme that loads a xml from a external file and not from the resources section ?
If there is, can someone please upload a example ?
guga,
Looks good ! :icon14:
HI steve...Tks :)
Btw: I found how to make visual styles externally. Just create a manifest file with the same name as the target app, and adding a extension ".manifest" on it. The contents should have this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="CompanyName.ProductName.YourApp"
type="win32"
/>
<description>Your application description here.</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
This can be created with notepad. In my case, i saved it as "CustProgressBar7c.EXE.manifest" and visual styles were enabled. (Also, the app must contains a call to initcommoncontrols).
Once i finished the tests on the new progressbar based on win7, i´ll see if the hook also works for the external manifest file directly.
you can embed the manifest into the EXE resources
it is actually an XML file, so i usually name it "program.xml"
then, in the resource file:
#ifndef CREATEPROCESS_MANIFEST_RESOURCE_ID
#define CREATEPROCESS_MANIFEST_RESOURCE_ID 1
#endif
#ifndef RT_MANIFEST
#define RT_MANIFEST 24
#endif
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "program.xml"
of course, you can provide a relative path if you put resources in a seperate folder
you don't have to define the constants - i do that because i like to know what they mean :P
1 24 "program.xml"
will also work
it doesn't change the size of the EXE
guga,
You are pretty safe using the external manifest file up to Win 7 64 bit, God know what will be the case with later versions but external manifests have worked since early Windows XP, Win2000 does not use them. You can embed a manifest into your resource section as Dave has mentioned so it depends what you want, a single exe or an external manifest that can be changed. Something I have done with a few older apps I own is to create a manifest file for them then they appear correctly in Win XP and Win 7 64 bit.
Hi steve
yeah...i´ll used them externally for now, since i didn´t finished the routine in rosasm that embed xml files in the resource section (I´ll do that later perhaps, once i restart the resource viewer app i was building a couple of years ago).
I´ll basically see if the technique i´m using in progressbar can also intercept a external manifest file. If it does, i´ll be able to test the internal coding that call the visual styles apis.