multiple library management

I recently got a 16x2 I2C lcd, typical of those on ebay. It has a 8574 i2c interface chip.

I have had mixed success playing with the various example files offered.
I have found that if i have, say, the New-liquidcrystal-master library installed ,and also the liquidcrystal-i2c library installed, (but not both #included) the LiquidCrystal_i2c that the compiler chooses may be the wrong one, with resulting compiler errors.

I have to actually delete to the recycle bin the library that is 'wrong' for that sketch and later restore it if i need it for a different sketch - rather clumsy and prone to error. The compiler seems smart enough to find library files even if i rename a library to try to 'hide' it. For example, the compiler finds #include <LiquidCrystal_I2C.h> in several libraries and they do not have identical functions which causes the compiler errors.

*******I do apologise, i just found the #include local files syntax which solves my problem. It seems I just need to copy the needed library over into the specific ino folder, just tried it and i get a lot less red from the compiler..

i may be off the beam here, but is there a way in a sketch to direct the compiler to the required library version?

For what its worth, if its at all relevant, i keep all my user sketches on a separate HDD in my own directory (not the default c:/users/name/docs/arduino) and all 'my' own library files are in a library directory within the sketches directory. The arduino core libraries are in the default location programfiles(x86).

If I'm asking the wrong question and there's a better way I'd like to hear it.
thanks,
mike

You are doing everything correctly and there have been very long standing issues with the libraries you mention.

There are two types of INCLUDE one of which may be of help.

Include "libname"
and
Include

There are so many of the LCD libs it can be a pita as they are often outside the control of Arduino.

It has been quite frustrating trying to find the correct library for the particular sketch to work when the compiler has chosen a library that does not support the instructions or parameters used.
I guess in future, unless the sketch author has clearly specified which lib to use, I'll just have to trial and error it by eliminating the one(s) the compiler says it has used but which failed.
I see that #Include "libname" looks first in the specific sketch directory, so once Ive determined the correct lib a copy will need to go there.

Unfortunately, at my level of knowledge, the compiler errors can also be somewhat obscure, and googling for them can lead to a rabbit warren.

Thanks again.

The variety of I2C lcd libraries is indeed annoying. But everyone that writes a library does that initially for his/her own use and later shares.

You actually need to pick one and stick to it. That does however mean rewriting code that you find on the internet which should not be that difficult.

sterretje:
You actually need to pick one and stick to it. That does however mean rewriting code that you find on the internet which should not be that difficult.

If I had 15 years experience as a software engineer that might be true. To even get a start i found using notepad to be impossible, and only gave me headaches trying to parse the text... Notepad++ was recommended and is so much better. But, I don't really want to learn C++, and the code in the *.h files and presumably *.cpp files would seem to require that.

Seeking more 'user' info usually leads me to links that no longer work (eg WIKI files). For example, the code in the HelloWorld_I2C example uses the following declaration;

LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

Somewhat obscure to me. Now, i now know that 0x27 is the I2C address of the interface chip (but I didn't even know what I2C was until a few weeks ago); the remaining numbers up to POSITIVE are something to do with pin assignations (I think) and POSITIVE determines the backlight state.
It would be really nice if there were a tutorial which explained what this was all about. For example why does an I2C declaration need to specify pin assignations - if that is in fact what is happening? I'd thought that the electronics physical connections determined the pin connections?

My background is an electrical/electronics engineer graduating back in 1972 when it was all one subject and included a little programming too. I haven't worked in a technical capacity for over 25 years and the microcontroller phase completely bypassed me - even my much more basic electronics knowledge could quite kindly be called rusty.

I am however interested and trying to get over some of that lack, by picking apart example sketches so as to understand and adapt others' code but don't have the time or interest to get into such as C++.

If you know of any such newbie/user aids, I'd be interested to learn. (PS I have spent many, many hours on the net and in these forums and am very grateful for the help and advice offered therein).
mike

I've just spent some time reading an entertaining albeit quite heated discussion in these forums regarding lcd-i2c libraries, changes and broken sketches as a result (maybe!!) of the changes. The discussion did not resolve much but did provide some answers to some of my questions in my previous post.

In the midst of the discussion i found a recommendation that the library to use is the hd44780 library by Bill Perry. It seems very up to date. Is this still considered to be the library with the widest application?

I also came across a LiquidCrystal_PCF8574 library which i tried as that's the I2C i'm using. It worked fine with the attached example and was quite educational for me as it was reasonably documented.

I like the idea of having one only LCD-i2c library, but which is likely to be the best for me? And, do i need to remove all the other lcd-i2c and lcd libraries to avoid the compiler using the wrong one?

If you want only one hd44780 LCD library the one to use is the hd44780 library by Bill Perry. It covers LCDs the 4 bit parallel, I2C with PCF8574 and MCP23008 I2C expander chips and I2C LCDs. For the I2C expander LCDs it will auto detect the I2C address and the pin mapping between the expander and LCD. It is faster than other LCD libraries and has other fine features. It is available for installation via the library manager.

And, do i need to remove all the other lcd-i2c and lcd libraries to avoid the compiler using the wrong one?

You do not need to remove the other libraries. I keep the others so that I can help users, on the forum, that are using those libraries. Of course I also recommend that they switch to hd44780.

groundFungus:
You do not need to remove the other libraries. I keep the others so that I can help users, on the forum, that are using those libraries. Of course I also recommend that they switch to hd44780.

Thanks! Ive just spent some time browsing Bill Perry's library and examples, and must say i wish i had found these some time ago. Kudos to Mr Perry for the fine work, and I'll get much education and satisfaction from exploring his comprehensive and well documented examples.

As i am not in a position of being able to help others, lacking the knowledge to do other than confuse, i will remove the less useful libraries (but not all) to minimise my likelihood of confusing myself!