This will be my very last post in this thread.
No you don't see path in the include. You see a subdirectory being specified on an include. BIG difference.
None of the headers included in hd44780 have a path to the directory where the library is installed
No Arduino sketch does. The second include is specifying a subdirectory that is relative to an include directory just like the first included header and all the included headers in arduino sketches.
The way Arduino handles what they call "libraries" can and does cause issues when there are header file collisions in libraries.
Some of the newer rules added to more recent IDEs are attempts to work around this but the issue is not solvable given the way they process their libraries and the way they use the -I include paths with the compiler.
There are alternative ways to handle this, I even proposed a few many years ago, but they rejected them, mainly I think because they didn't understand the real issue until very recently.
Conflicting? Contradicting? I do not see any two statements that say I did this and then say I did that. May be short on information, mostly that I don't know and/or cannot now find. But neither conflicting nor contradicting.
Really? You honestly still don't see any of the issues?
In post 11 you said you were using the fm newLiquidCrystal library v1.3.4 from the bitbucket site.
Given the code in that library, it will not work with your hardware. That is a fact.
newLiquidCrystal 1.3.4 uses the same default pin mappings as 1.3.5 and the i2c lcd code is the same for both of those libraries and that default pin maping is for the LCDXIO board which will not work with you LCD device.
So that is a situation of two things in direct conflict, you say you are using newLiquidCrystal by only specifying the i2c address in the constructor and yet that will not work with any version of newLiquidCrystal library code from fm's bitbucket site.
This is what caused david to say "I don't believe you".
He got it right in that it is impossible for you to be actually using fm's newLiquidCrystal library with the single i2c address parameter you say you are using and have it working.
It simply is not possible.
You were not using the library you were telling us you were using, or were using it differently than the way you were saying you were using it.
So that is a big conflict in information.
Here another guess on what could have happened based on something I just noticed.
This what I just noticed that could be a clue:
In your code in post #11 there is this line:
//LiquidCrystal_I2C lcd(0x38, BACKLIGHT_PIN, POSITIVE); // Set the LCD I2C address
That is not a valid constructor parameter list for newLiquidCrystal. Further, it is not a valid constructor list for any i2c LCD library I've ever seen that uses a LiquidCrytal_I2C class, and I have looked close to 20 different ones.
The LiqiudCrystal_I2C library does have a constructor that takes 3 parameters but those are not them.
That library uses:
LiquidCrystal_I2C(uint8_t lcd_Addr,uint8_t lcd_cols,uint8_t lcd_rows);
There are 3 parameters, but the 2nd two are the cols and rows of the LCD.
That library historically used lcd.init() instead of begin(cols,rows) but newer versions added begin(cols,rows)
If you had the newer LiquidCrystal_I2C library and passed in a backlight pin instead of cols, and POSITIVE instead of rows (which would be incorrect), it could still work if also used lcd.begin(cols,rows)
So if prior to doing your updates you were also using
LiquidCrystal_I2C lcd(0x38, BACKLIGHT_PIN, POSITIVE) and had the LiquidCrystal_I2C library installed and calling lcd.begin(cols, rows) instead of lcd.init() as shown in your sample code in post #11
it would work, as you would be using the LiquidCrystal_I2C library which uses the same default pin mapping as your hardware.
But that would be a VERY BIG detail that you left out and would have instantly told us about a messed up installation of multiple LCD libraries.
I have no idea as to what you actually did, but you had to have installed multiple i2c LCD libraries. No question there.
And like I said before, there can and will be issues when you have multiple library directories with header files by the same name.
This is a great example of what can happen when installing/using multiple libraries that have a header file with the same name.
This issue is quite common when using newLiquidCrystal and any of the LiquidCrystal_I2C library varieties.
And I have seen many users screw up their installation when they are playing around with multiple i2c lcd libraries and/or with newLiquidCrystal when not following the installation instructions on fm's site.
And now I'll say goodbye to this thread.
--- bill