ScaleRichView update and MouseWheel is dead

[GoranBru]

Hi,
We are updating the software from Delphi Sydney to Delphi 13.1 Florence as well as components. In Sydney we used TRichView 23.2 and TScaleRichView 12.4.1, in Delphi 13.1 the RV is now 24.1.3 and SRV 12.5.3. In old version one could normally scroll the document accross the pages, now it does not work anymore. Even Control+mouse scroll did change zoom, now it does not work anymore. There are no code on events connected to mouse scroll.
I tried building the TSRV demo ActionTestUni but interestingly, there the mouse scroll works as it is supposed. Has anything changed connected to mouse scroll?

Thank You and best regards,
Goran

[standay]

You may need to add MOUSE to your USES section. Sergey may have a better answer but adding the declaration is easy to try.

Stab

[GoranBru]

Hi,
thanks for the help but it did not help. But I dug deeper into the problem and found out that code HookMouseWheelEvent in SclRView does not do its job since the RVWIN10 variable says False. But on ScaleRichView demo it says true on the same machine. I dug deeper and got to the RVUni.pas file, to the RVCheckNT procedure where in the demo project it correctly identifies OS version, in my application it does not. So TOSVersionInfo says in my application:
dwOSVersionInfoSize = 276
dwMajorVersion = 6
dwMinorVersion = 2
dwBuildNumber = 9200
dwPlatformID = 2

In SRV demo
dwOSVersionInfoSize = 276
dwMajorVersion = 10
dwMinorVersion = 0
dwBuildNumber = 26100
dwPlatformID = 2

In my Application I use DSiWin32 unit which correctly reports windows version. But it uses TOSVersionInfoExW in Winapi.Windows.

[GoranBru]

Okay, somehow even though I have in Project options-Delphi Compiler RVKERNELWINVERCHECK, the procedure RVCheckNT in RVUni.pas ignores it and gets incorrect Windows version. So in DPR I added RVUni unit and added the line
RVUni.RVWin10 := True;
and now the mouse works correctly now. All users have either Windows 10, either Windows 11 so it is okay now.

[Sergey Tkachenko]

Do you have a custom manifest file in your application?

[GoranBru]

Yes, we have it.

[Sergey Tkachenko]

Your application returns data corresponding to Windows 8 because its manifest does not specify compatibility with newer versions of Windows. Most likely, the <compatibility> section is missing.

The best solution is to fix the application manifest. However, you can also try recompiling TRichView with the RVKERNELWINVERCHECK conditional symbol $defined. In this case, it will check the Windows version using a function that does not depend on the application manifest.

[GoranBru]

Here is the manifest; some info were slightly changed. It works well in HighDPI as well as in normal DPI in Windows 11.

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
	<assemblyIdentity type="win32" name="ourapp.exe" version="3.0.0.0" processorArchitecture="*"/>
	<dependency>
		<dependentAssembly>
			<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" publicKeyToken="6595b64144ccf1df" language="*" processorArchitecture="*"/>
		</dependentAssembly>
	</dependency>
	<dependency>
		<dependentAssembly>
			<assemblyIdentity name="NetLibrary" version="3.4.4.0" processorArchitecture="msil"/>
		</dependentAssembly>
	</dependency>
	<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
		<security>
			<requestedPrivileges>
				<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
			</requestedPrivileges>
		</security>
	</trustInfo>
	<asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
		<asmv3:windowsSettings>
			<!-- Per Monitor V1 [OS >= Windows 8.1] 
			 Values: False, True, Per-monitor, True/PM -->
			<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
		  true/PM</dpiAware>
			<!-- Per Monitor V1 [OS >= Windows 10 Anniversary Update (1607, 10.0.14393, Redstone 1)]
			 Values: Unaware, System, PerMonitor -->
			<!-- Per Monitor V2 [OS >= Windows 10 Creators Update (1703, 10.0.15063, Redstone 2)]
			 Value: PerMonitorV2 -->
			<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
		  PerMonitorV2, PerMonitor</dpiAwareness>
		</asmv3:windowsSettings>
	</asmv3:application>
	<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
		<application>
			<!--The ID below indicates application support for Windows Vista -->
			<SupportedOS ID="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
			<!--The ID below indicates application support for Windows 7 -->
			<SupportedOS ID="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
			<!--The ID below indicates application support for Windows 8 -->
			<SupportedOS ID="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
			<!--The ID below indicates application support for Windows 8.1 -->
			<SupportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
			<!--The ID below indicates application support for Windows 10 -->
			<SupportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
		</application>
	</compatibility>
</assembly> 

[Sergey Tkachenko]

This manifest must not cause problems with Win10/11 detection.
Can you double check that this manifest is really used and is not overridden by some other manifest?

[GoranBru]

It is definitely in use otherwise we can't use the "NetLibrary" which is in dependecy section.

[Sergey Tkachenko]

Then I don't know why GetVersionEx behaves this way.
Try defining RVKERNELWINVERCHECK, so RtlGetVersion will be used.

[GoranBru]

Well, I did this as well but

Code: Select all

{$define RVKERNELWINVERCHECK}

or

Code: Select all

{$define RVKERNELWINVERCHECK ON}

do not help. The definition is just after

Code: Select all

{$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

and all resource used in software.

So I ended with adding this definition as well as

Code: Select all

RVUni.RVWin10 := True;

This works properly. I don't know why such behavior either but at it works, everybody's happy .

[Sergey Tkachenko]

If you use Win32 platform and did not change the installer option for adding path to source files for Win32 platform, RVKERNELWINVERCHECK can be defined in the project options. Page "Building | Delphi Compiler", the field "Conditional defines" is the semicolon-delimited list of compiler defines. You can add RVKERNELWINVERCHECK there.

If you use Win64 platform or chose the installer option to add path to precompiled units for Win32 platform, it's more difficult.

[GoranBru]

For few future versions we'll stay with Win32, then we'll switch to win64. In any case, in conditional defines RVKERNELWINVERCHECK is there.
As I said, I found the solution that works. It is may well something coded somewhere that obstructs the proper recognition and at the moment it is okay. I hope no one else will have such problem but he/she may try my solution. I do not think it is worth researching anymore