Listview progressbar control

[John Z]

It seems that WIN11 is intolerant to UNICODE/ANSI mixing, WHILE WIN10 was more easygoing on that. 

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

[frankie]

It seems that WIN11 is intolerant to UNICODE/ANSI mixing, WHILE WIN10 was more easygoing on that. 

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... 

[Pelle]

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 ...

[frankie]

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 ...

[John Z]

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...

[Vortex]

UNICODE and those code pages are always headaches. Better to stay with Windows 10 and 7.

[Pelle]

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.

[John Z]

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

[frankie]

And compiling for 32bits works even without UNICODE.
Thanks for the test John.

[Pelle]

OK, I'm lost. I have no idea what is and isn't working here. I'm done with this.

[frankie]

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... 
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... 

[Vortex]

We can retry the same test after the release of Windows 11 23 H2.

[John Z]

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

[frankie]

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. 

[John Z]

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.