adwsystems:
That's fine. What was the error? I hate making the same mistake twice.
I already posted my best guess as to what you did - which is the only thing that makes sense and accounts for all things you described as happening.
Yes, seriously. Since I didn't change the library there was no fruitful reason to check it, but for post #21 I not only checked it but compared new told. Low and behold I was right, there were no changes to that library.
We asked you to compare the library you said worked to the one you said didn't but you never did.
If you had looked you would have seen that they were the same and at least I would not have wasted so much time
as I would have chosen to move on sooner since you don't know what library code you were really using.
You changed something, an it likely involved a manual installation issue.
Any time you use fm's library you must make manual changes to the system since you can't use it until you get the IDE bundled LiquidCrystal library out of the way. There are several ways to do that and many of not most users do not bother to read the actual instructions on fm's page for how to do it and do it wrong. While it usually still works, it can get them in to trouble later.
This is compounded by the fact that depending on which version of the IDE you are using and which version of the newLiquidCrystal code you have, you may also have to make changes to fm's library code to get things to compile.
But none of that explains how you had a working library with the constructor you say was working.
The code you say you were using and even provided would not work with your LCD device.
You have yet to show us any i2c LCD library code that would work with the constructor you say you were using.
So at some point in time, you installed something or edited something in some version of an i2c LCD library installed in one of the several possible libraries directories on your system to make it work and forgot about.
Question: Are all of the libraries load via the library manager held in the documents->arduino->libraries folder?
Yes, but there are multiple libraries directories besides that one. The IDE will scan all of them and look into each library directory for an included header file. The IDE has a priority mechanism to determine how to select which directory to use when there are header file name collisions, as the case of having multiple libraries installed with a "LiquidCrystal_I2C.h" or "LiquidCrystal.h" header file. (Note that the priority rules inside the IDE has changed slightly over the years as well)
The way Arduino does its libraries is very screwy and is a lot of work inside the IDE. No other development system works this way. It also can cause lots of strange and unexpected issues like using a different library than expected when there are multiple libraries installed that have header files with the same name - which I believe is what was happening to you.
Somewhere at some point you installed a newLiquidCrystal library somewhere else and modified it to work with your h/w.
If it is, it isn't in the libraries folder. The sketch is posted, so you can see the include statement does not include a path (like hd44780 requires).
What do you mean by "does not include a path (like hd44780 requires)" ?
The hd44780 library works just like any other library with respect header files in the sketch.
i.e.
#include <hd44780.h> // main hd44780 header
#include <hd44780ioClass/hd44780_I2Cexp.h> // i2c expander i/o class header
are not specifying a path or where the header files live.
The IDE still must scan multiple Arduino library locations to locate the directory where the hd44780 library lives just like any other Arduino library.
The only thing I can recall I had to do was to remove Arduino's LiquidCrystal library to not conflict with fmalpartida's. I must wonder if pert had it back in post #2. A library was installed and deleted. Then I installed fmpartida's library, but the old library was not completely gone and the sketches picked up on parts of both allowing the sketches to work. It appeared (appears) that I only had fm's library installed, but in fact had 1 1/2 libraries. The updates to one (or more) of the libraries removed the half thus breaking my sketches.
Sounds very unlikely that a library was only partially deleted but still existed enough to still work.
I don't even believe that is possible. If it is there enough for the IDE to see it, it is still there and you could see it.
To do any of that would require doing some manual installation/configuration/modification - and recall that incorrect manual library installation and/or configuration was what I said I believe the issue to be.
And then beyond all that, I have yet to see any i2c LCD library that had a default pin mapping that used a constructor like you said you were using.
This isn't an issue of switching to a new version of newLiquidCrystal that breaks your code, it is a case of you doing some things, including some manual manipulations of your libraries that you don't remember - which supposedly got things to work.
Then later you did some things which includes updating the newLiquidCrystal library, which you also can't fully remember which broke your supposedly working system.
You can't remember what you did, nor have you been able to show us any i2c LCD library code that works the way you say the code works for you.
Given all these unknowns and conflicting information there is no way I can help you and am not going to waste any more of my time on this.
--- bill