Pelles C forum
C language => User contributions => Topic started by: frankie on October 22, 2023, 09:40:40 PM
-
Following a post about a listview progress bar control I felt a compulsive necessity to produce a control usable for any listview window. ::)
So I produced the code below that:
- Is completely transparent to the user.
All graphical and system code is inside the control module, including memory allocation and freeing.
The user interface make available, actually, just 2 functions 5 functions, one to create the progress bar inside a list view at specific row and column, and the other to set current progress for a specific bar, the last 2 to set and retrieve progress bar properties. Added destroy function that can remove a single ListView control or all child controls. (V.2.02)
- More listview controls can be handled.
- The graphic can include or not the current percentage value in text.
- High contrast text (color changes againt background to maintain high contrast).
- Can prepend a text string to the percentage.
- The progress bar can be positioned in the first column without occupying the whole row.
- Made available the destroy function (V2.02).
If you pass the ListView control handle it will destroy only that control, if you pass the parent window handle, it will destroy all controls and remove the subclassing (full remove).
- Correctly handle theme change now (V2.02).
In hope it could be of any use... :)
EDIT: Updated version V2.02. Fixed some bugs and added new feature.
-
Hi frankie,
Impressive work.
-
Hi frankie,
Impressive work.
Thanks Erol :)
-
Nice job Frankie ... I wish I had a need for this.
Until that time arrives, I plan to run ListviewProgressBar.exe anytime I need to look busy. ;D
-
Hi frankie:
Your .exe doesn't work on my Windows 11 x64 machine.
I recompiled and still nothing when I tried to run the .exe.
Redownloaded and as above no luck.
:'(
-
Hello,
I can confirm Robert's test result. The executable does not display the GUI on Windows 11.
-
Hello,
I can confirm Robert's test result. The executable does not display the GUI on Windows 11.
Unfortunately I don't have a WIN11 machine to test right now. :-\
I made some modifications and added a manifest resource to force commoncontrols version 6.00.00
Let me know if this works.
The new version has been loaded in the first post of this thread.
-
Hi frankie,
Thanks for the update. The result is the same, the GUI does not appear :
C:\>ListViewProgressBar.exe && tasklist | findstr "ListViewProgressBar.exe"
ListViewProgressBar.exe 3940 Console 3 8.448 K
Some seconds later :
C:\>tasklist | findstr "ListViewProgressBar.exe"
Tasklist does not return anything.
Tested on Windows 11 2022 H2, Version 10.0.22621.2428
-
You just need to disable Optimization under code generation.
Yes I'm on Win 11 22H2 and Pelles C V12.00.2
Works fine then.
John Z
Update:
Level 2 warnings show 2 places with "Dead code removed (around here)." ...
these are both on macro statement
ListView_GetSubItemRect(pCustomDraw->nmcd.hdr.hwndFrom, pCustomDraw->nmcd.dwItemSpec, pCustomDraw->iSubItem, LVIR_BOUNDS, &rcBar);
which invokes
(BOOL)SNDMSG((hwnd),LVM_GETSUBITEMRECT,(WPARAM)(int)(iItem),((prc)?((((LPRECT)(prc))->top = iSubItem),(((LPRECT)(prc))->left = code),(LPARAM)(prc)):(LPARAM)(LPRECT)NULL))
I suspect optimizer might be having issues with (prc)? parameter 3 ... but this is just a guess. To test the (prc)? parameter could be broken out into one line which then precedes a standard SendMessage statement with the parameters rather than the macro.
-
Hi John,
You just need to disable Optimization under code generation.
Yes I'm on Win 11 22H2 and Pelles C V12.00.2
Works fine then.
Confirmed. Rebuilding the application without optimization solved the issue on Windows 11. Thanks.
-
Could you test this version with optimizations on?
I corrected some bugs and removed macros.
-
Attached.
Compiled and ran with optimizations including extras. Probably some UTF-8 issue though unless you too know Chinese... :)
John Z
Update
Without optimization - no 'Chinese' ;D
-
Probably some UTF-8 issue though unless you too know Chinese... :)
Well I speak a little poor chinese... But can't write or read it ;D
Could you check also this please?
Can't really understand what could be the point.... :-\
Anyway what's sure is that the compiler mess-up the code when optimizing the macro ListView_GetSubItemRect. >:(
-
Well I speak a little poor chinese... But can't write or read it ;D
Me too, speak and understand some but illiterate except for my name!
----
Anyway you nailed it. Works with full optimization.
John Z
-
Anyway you nailed it. Works with full optimization.
John Z
Good :)
It seems that WIN11 is intollerant to UNICODE/ANSI mixing, WHILE WIN10 was more easygoing on that. :P
OK ladies and gentlemen to use this code under WIN11 you must always use UNICODE.
To me another reason to stay with WIN10 for now... ;D
If there ane no more problems I'll move the last code to main post.
-
It seems that WIN11 is intolerant to UNICODE/ANSI mixing, WHILE WIN10 was more easygoing on that. :P
Well can't fully blame Win 11 though because the code w/o UNICODE flags does work perfectly when no optimization is used.
So there is some optimization interaction corrupting the text in a periodic manner in column 0 which the UNICODE flags mitigate. Every third column A text is correct too .... regardless of optimization or UNICODE. Just saying ....
But hey it is a UNICODE world now anyway ;D
John Z
-
It seems that WIN11 is intolerant to UNICODE/ANSI mixing, WHILE WIN10 was more easygoing on that. :P
Well can't fully blame Win 11 though because the code w/o UNICODE flags does work perfectly when no optimization is used.
So there is some optimization interaction corrupting the text in a periodic manner in column 0 which the UNICODE flags mitigate. Every third column A text is correct too .... regardless of optimization or UNICODE. Just saying ....
But hey it is a UNICODE world now anyway :)
John Z
This is exactly my sensation. There is an insidious bug sneaking in the shadows behind the scene... :-\
I can't conduct any test without a WIN11 machine (but I don't want one now).
John last test you could do is compiling for 32bits to see if the problem is still there... :(
Yes this is a UNICODE world... :)
-
1) The smallest difference between the working and non-working version would be nice, but I'm not sure how to get it.
2) The wrapper macros in <commctrl.h>, <windowsx.h> etc. are full of casts, which basically tells the compiler to shut up and do what it's told. I'm not saying this is the problem here, but casts can hide a lot of bugs.
3) I completely agree on staying away from Win11 ...
-
1) The smallest difference between the working and non-working version would be nice, but I'm not sure how to get it.
I can't actually see it, at least without an assembler full immersion.
2) The wrapper macros in <commctrl.h>, <windowsx.h> etc. are full of casts, which basically tells the compiler to shut up and do what it's told. I'm not saying this is the problem here, but casts can hide a lot of bugs.
I agree, but removing macros has been the first step toward resolution.
Maybe the casts triggers a collateral bug?
3) I completely agree on staying away from Win11 ...
;D
-
John last test you could do is compiling for 32bits to see if the problem is still there... :(
Using the version before adding the UNICODE changes and compiling for 32 bits with speed optimization and extra optimizations - It works perfectly.....
John Z
Windows 11 share is about 20-25%, expectations are higher for 2024 as EOL on Win10 is reached....
I have Win 10 and Win 7 systems too, but wouldn't seem to be helpful since frankie is already doing Win 10...
-
UNICODE and those code pages are always headaches. Better to stay with Windows 10 and 7.
-
If I understand correctly, version 1.04 did not work but version 1.05 does. Correct?
If so, using IDE "Differences" I can see that the only (source file) changes went into main.c: defining UNICODE and _UNICODE, changing some literals into wide literals (".." to L".."), and one case of CHAR into TCHAR. None of this can be affected by the optimizer. A Windows problem.
-
Well, not exactly.
1.04 did work in that the program actually displayed and showed everything including the progress bars. However that version has the issue with 'Chinese' looking characters showing on every two out of three rows where 1 row good, next two corrupted text in column 0, next good then two more bad, etc.
Prior to version 1.04 which replaced the macro it would not run at all.
In 1.05 adding UNICODE flags 'fixed' the column 0 corrupted text. Of course UNICODE flags invoke different handling.
John Z
-
And compiling for 32bits works even without UNICODE.
Thanks for the test John.
-
OK, I'm lost. I have no idea what is and isn't working here. I'm done with this.
-
OK, I'm lost. I have no idea what is and isn't working here. I'm done with this.
Don't follow me I'm lost too... ;D
I think that we have superimposed effects, some compiler minor bug (maybe also a register to preserve), and some WIN11 major bug ::)
No other explanation for the different behavior in WIN10 and WIN11... :(
-
We can retry the same test after the release of Windows 11 23 H2.
-
Summary:
Initial version 64bit on Win10 worked with optimization ON
Initial version on Win11 failed to even show up with optimization ON
Initial version on Win11 worked with optimization OFF
suspect was a particular macro function
suspect macro function was removed and replaced by SendMessage
1.04 version on Win11 worked with optimization OFF
1.04 version on Win11 partially worked with optimization ON
issue was foreign characters in two out of three consecutive lines
Looked like a UTF-8 issue...
1.05 version changed to using UNICODE
1.05 version on Win11 worked with optimization ON
1.05 version on Win11 worked with optimization OFF
1.04 version on Win11 with 32 bit compile
1.04a version worked on Win11 with optimization
1.04a version worked on Win11 with optimization OFF
Every version worked on Win11 whether 32bit or 64bit when optimization was OFF
For 64 bit Win 11:
A macro was found to problematic with optimization 1.04 on Win11, such that
even the main window did not appear and the program crashed immediately
The cause for 'needing' UNICODE was not isolated but somehow optimization
was doing something that Win11 did not like, but enabling UNICODE in 1.05
mitigated the thing Win11 did not like with optimization.
John Z
-
Summary:
.....
John Z
Thanks John :)
This was really useful.
If you have time would be helpful also a check on 32bits compilation of all versions, especially those not working.
If 32bits compilations works, then reasonably we have a problem with the compiler. :(
-
In version 1.04 which is the version prior to adding UNICODE(bandaid)
The 64 bit optimization issue is in procedure AddLvProgressBar which is in ListViewProcessBar.c.
The exact line causing the failure is
lvItem.mask != LVIF_PARAM;
Under 32 bit this is not an issue with optimization but with 64 bit
optimization it appears to corrupt lvProgress in some manner.
It can be fixed by changing the line to
lvItem.mask = LVIF_PARAM; // un-confuse 64 bit optimization
Now the program works correctly under both 64 bit optimization and 32 bit optimization.
John Z
Update: This also appears to have allowed the macro ListView_GetSubItemRect to work correctly even though dead code removal message still exists. So this macro could have been a red herring, but by changing the program structure by using SendMessage and with the rcItem.top , rcItem.left statements it got by the issue partially.
-
In version 1.04 which is the version prior to adding UNICODE(bandaid)
The 64 bit optimization issue is in procedure AddLvProgressBar which is in ListViewProcessBar.c.
The exact line causing the failure is
lvItem.mask != LVIF_PARAM;
Under 32 bit this is not an issue with optimization but with 64 bit
optimization it appears to corrupt lvProgress in some manner.
It can be fixed by changing the line to
lvItem.mask = LVIF_PARAM; // un-confuse 64 bit optimization
Now the program works correctly under both 64 bit optimization and 32 bit optimization.
John Z
Very good job John! :D
I've never noted that typo, even after checking the whole file more and more time.
Now it's me that should pay you a a beer or a KEG! ;D
Everything should be clear now, the wrong statement or'ed the rubbish in the variable with the required flag, then WIN11 strongly checked for invalid flags and aborted, or eventually interpreted them as new flags showing 'chinese' characters.
Win10, easygoing, ignored errors.
P.S. Maybe also ListView_GetSubItemRect macro works now... :P
OK. I'll continue to stay with WIN10! 8)
-
Everything should be clear now, the wrong statement or'ed the rubbish in the variable with the required flag, then WIN11 strongly checked for invalid flags and aborted, or eventually interpreted them as new flags showing 'chinese' characters.
Win10, easygoing, ignored errors.
Well .... I don't think it was rubbish - It should have been 0 because
LISTVIEWPROGRESS *lvProgress = calloc(1, sizeof(LISTVIEWPROGRESS)); // calloc set all to 0
So I think the 64 bit optimizer and Win 11 involved somehow... Also tried
lvItem.mask = lvItem.mask | LVIF_PARAM; just in case but it was BAD as well with 64 bit optimization.
Also if rubbish it should still be rubbish without optimization .... yet it works correctly without optimization.
Also as 32 bit, with and without optimization, it worked with lvItem.mask |= LVIF_PARAM;
P.S. Maybe also ListView_GetSubItemRect macro works now... :P
YES see update to prior post.... seems fixed
John
P.S. Last post on this I think. It is working ....
-
John lvProgress is initialized to 0, but the problem is on lvItem that is an uninitialized local variable.
Evidently the optimization process influence the contents of memory and then what we found inside the uninitialized variable.
Everything is more clear... :P
At this point the compiler should be ok... ::)
-
frankie - the beer is back to you!
Yes I saw(incorrectly) it was zeroing everything not noticing it became item instead of progress! >:( even though I was changing lvItem.mask DUH!
It is clear now ! Thanks!
John Z
-
frankie - the beer is back to you!
Yes I saw(incorrectly) it was zeroing everything not noticing it became item instead of progress! >:( even though I was changing lvItem.mask DUH!
It is clear now ! Thanks!
John Z
John don't worry, this is a perfectly normal, humane, situation. It is called "motivated perception", we see what stimulate us, what we want see (see (https://www.psychologytoday.com/us/blog/between-cultures/201907/why-we-see-what-we-want-see)).
This happens continuously, we need a bug of the OS or the compiler to stimulate our self-motivation 8).
What about a couple of pints? ;D
-
HI frankie,
Say - don't forget to re-post the 1.04 version at the top of this thread with the fix for your admiring followers !
Was it intentional to use the multithread Lib?
My motivated perception sees that pint as a quart :) :) :), each....
John Z
-
HI frankie,
Say - don't forget to re-post the 1.04 version at the top of this thread with the fix for your admiring followers !
Was it intentional to use the multithread Lib?
Done.
Yup, it is always better to use multithreaded version because almost everything is multithreaded (almost always concurrent threads are started automatically from SYS calls).
My motivated perception sees that pint as a quart :) :) :), each....
John Z
Right now I see 2 empty mugs... ;D
-
Very cool frankie!
Not only fixed but enhanced. Worked fine on the now notorious Win 11 :)
John Z
-
Updated to V2.00.
Right click on each subitem to add, remove and modify progress bar. ;)
Download from the The first post of this thread (https://forum.pellesc.de/index.php?topic=11012.msg38485#msg38485).
-
Hi frankie,
Version 2.00 works fine on Windows 7 64-bit. Thanks.
-
Hi frankie,
Version 2.00 works fine on Windows 7 64-bit. Thanks.
Thanks Erol, I hope it works in W11 too... :)
-
[Thanks Erol, I hope it works in W11 too... :)
Works like a charm frankie, great work, and useful feature too.
Yes, WIN 11 22H2 with PellesC V12, built it and ran it - no issues
John Z
-
Works like a charm frankie, great work, and useful feature too.
Yes, WIN 11 22H2 with PellesC V12, built it and ran it - no issues
John Z
Thanks John
Happy it works well. :)
-
Hi frankie,
The test is successfull, V2.0 works on Windows 11 22 H2, Microsoft Windows [Version 10.0.22621.2428]
-
Nice to hear, that this site have couple active testers for Win 11 and it's very good thing.
-
Hi Timo,
Not sure but it appears that the prefetch feature of Win 11 is a bit slow. You need to wait for some seconds after executing ListViewProgressBar.exe for the first time. No any antivirus software on the test computer.
C:\Windows\Prefetch
-
Hi Vortex,
How is that checked? On my system I really don't see a hesitation visually, so I'd like to know how to determine that. I deleted all ListViewProgressBar entries in C:/windows/prefetch but still don't see a hesitation.
Thanks,
John Z
-
Hi John,
My test computer at work ( with a Core i7 processor ) is an old one. Probably, your computer has a NVMe storage. Try to delete all the entries in the folder C:\Windows\Prefetch and restart the computer.
By the way, Microsof released Windows 11 23 H2 :
https://www.microsoft.com/software-download/windows11
-
Hi Vortex,
Yup - tried deleting Prefetch, no visual difference.
I've got an I7 10th gen but it is a U version so somewhat limited.
However I do have an SSD and it also has Optane so as you mentioned this is probably the driver. :)
When I opted for Optane SSD I certainly didn't expect Intel to drop it.
I had to buy up a spare 512G Optane SDD to keep so that I could replace the systems SDD if it went bad before they all disappeared.
Yeah, Win 11 23H2 - I always wait until it is a forced install by then most issues should have been worked.
John Z
-
Hi John,
Today, I installed Windows 11 23 H2 on the same computer. Frankie's application ran without any latency.
-
@Pelle - I was done with this before this even started. I knew this was coming, because there was zero coverage on this anywhere in this forum board.
I dont dare post any of my current development.. that will be multiple fires to put out, not just 1 lol.
I feel there is too much invested into text formatting, outside the realm of the expectation and the original issue at hand, which was well resolved before spawning a new topic. Leave the implemented string formatting up to the user downloading the sample code.
My copy has had several improvements since I last visited this forum, to my surprise this topic blew up in my face. Now I dont know what is going on, but it doesn't matter. I see successful results on Windows 7 - 11 (I wont touch Windows 11, user tested).
I really dont see what the issues are here as of late, but it is a grain of salt to me at this point. No issues, so I dont care, etc.
Credit goes to original author @ posted URL. Enjoy.