Sounds more like the second constructor in the demo code was uncommented
which would then mean there would be two declarations for the constructor.
fm,
On a somewhat unrelated note, this brings up an interesting "issue" in the current library.
Currently the function setBacklightPin() is used to set the bit within the output latch
on the communication interface.
i.e. in the I2C code it is a bit that is used on the other side of the i2c interface
and in the SR3W code it is a bit on the SR output latch. (SR and SR2W don't support this function)
But the potential issue is that some boards, like the I2C extra I/O LCD board don't support
controlling the backlight through the interface, they require using an additional Arduino pin.
The library "as is" has no support for this mode of operation, so users are left to having
to use Arduino core functions like digitalWrite()/AnalogWrite() to control the backlight rather
than being able to use the library functions like backlight(),noBacklight() and setBacklight().
What might be nice would be if the code supported using both modes of operation.
i.e. it could use an output pin within the existing interface or assign an Arduino pin
that works outside the interface.
In the glcd library I use some argument overloading (hidden from c++) to handle a few complex arguments.
While it does side step the normal C++ typechecking, it is easy to do and this library could do the same.
It uses a macro to alter the parameter in a way that it can be distinguished.
So for example, it would be possible to do something like:
LiquidCrystal_I2C lcd(0x38, LCD_ARDUINO_PIN(BACKLIGHT_PIN), POSITIVE); // Set the LCD I2C address
This would allow the constructor or other functions to be able to tell if the argument
is a bit on the output latch or an actual Arduino pin.
The glcd library version of this type of macro simply negates the value by inserting a minus sign.
This allows to code to quickly and easily detect which type of argument is desired.
In this example it would be:
#define LCD_ARDUINO_PIN(pin) (-pin)
The code receiving the argument can simply look if the argument is negative to tell
if it indicates and Arduino pin vs an interface output latch bit.
Some of the needed support for this would move up to the LCD common code and then depending on the
type of backlight "pin" control selected, it would either handle itself , in the case of an arduino pin, or call
the device layers backlight functions.
It is all doable and not very much code, and while it would allow the existing I2c Extra I/o board
to have backlight control, I haven't seen any other boards out there that use a latching interface
to the LCD and then use a separate Arduino pin for backlight control so
it may not be worth the effort to add this support.
--- bill