Warning W0: Case does not mach

After upgrading to Elements 2289 (with Visual Studio 2015), I begun getting Warnings (W0) “Case of identifier xx does not match original case” in situations like this:

type
  BaseClass = public class
  protected
     method GetSomething: Integer; virtual; empty;
  public
    property Something: Integer read GetSomething;
  end;

  DerivedClass = public class(BaseClass)
  protected
     method GetSomething: Integer; override; // Shows W0: Case does not match "getSomething"
  end;

I know that there is some hocus-pocus going on with getter and setter names behind the scene, but I never defined getSomething myself, so the warning is inappropriate.

That seems wrong. what platform?

java

Thanks, logged as bugs://80625

bugs://80625 got closed with status fixed.

It seems that bugs://80625 has not been completely fixed, because I am still getting similar errors in Elements 2331.Furthermore, this bug seems to cause a bizarre and very annoying behavior of Water when switching between java and .NET projects that use common platform-independent code.

Please look at the uploaded solution:
TestGetSet.zip (72.5 KB)

and observe line 34 in Code.pas. First, notice the warning, which occurs under java, but not under .NET:

W: Case for identifier “GetLowIntBound” does not match original case “getLowIntBound”

The warning is obviously wrong because there is no “getLowIntBound” in my code.

Then, try switching between TestJava and TestNet in Water. Build and observe how each platform changes the code in its own way, overriding the change made previously by the other platform.

Could you, please, check my previous message in this thread? It seems it has been overlooked.

I’ve just checked the test case from TestGetSet.zip with 10.0.0.2395, and the problem is still there.

If you shared code between platforms that use camelCase vs PascalCase, you’ll want to turn omg Cross Platform mode, otherwise, yes, you’ll keep warnings about case-mismatches on ONE of them (and auto-fixes, ion you have those turned on), because method names, such as toString simply don’t match…

That said, this doesn’t apply to GetLowIntBound, that does seem like a big, re-logging.

Thanks, logged as bugs://82493

bugs://82493 got closed with status fixed.

I understand the issue about toString and have no problems with that.

In version 10.0.0.2405, case checking works better, but the bug seems not to be entirely fixed. Please see the uploaded solution TestGetSet2.zip (112.9 KB)

bugs://82493 got reopened.

bugs://82493 got closed with status fixed.

Elements 10.0.0.2409

Still not completely fixed, please see TestGetSet3.zip (43.6 KB)

hrmm maybe I’m missing something but compiling that does not give me any warnings?

Please see:

The same happens in Water, too.

I am getting the following warnings:

------ Build started: Project: TestJava, Configuration: Debug ------
D:\RemObjects\TestGetSet\Code.pas(354,35): warning W0: Case for identifier "GetLowFltBound" does not match original case "getLowFltBound"
D:\RemObjects\TestGetSet\Code.pas(355,36): warning W0: Case for identifier "GetHighFltBound" does not match original case "getHighFltBound"
D:\RemObjects\TestGetSet\Code.pas(360,32): warning W0: Case for identifier "GetFltRange" does not match original case "getFltRange"
D:\RemObjects\TestGetSet\Code.pas(518,17): warning W0: Case for identifier "GetFltRange" does not match original case "getFltRange"
D:\RemObjects\TestGetSet\Code.pas(467,35): warning W0: Case for identifier "GetCount" does not match original case "getCount"
D:\RemObjects\TestGetSet\Code.pas(472,34): warning W0: Case for identifier "GetIntRange" does not match original case "getIntRange"
------ Build started: Project: TestNet, Configuration: Debug ------
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========

These warnings occur only in Java environment (project TestJava)

No indication that you noticed my previous message. Have you managed to reproduce warnings that I receive?

bugs://82493 got reopened.

My apologies for the delay; this did not repro for Carlo initially, but it does for me, so I’ve reopened it.

Indeed sorry; I lost track of this issue.