Hello! I have come across a problem while programming a TFT. I want the TFT to be able to flip between addressable LED modes of an LED strip that is connected to the same arduino as the TFT. However, I evidently use the delay() function in a loop to make cool patterns on my LED strip, and this interferes with the touch screen. While I may have a 10ms refresh rate for the touch screen, the LED strip might change every 100ms, preventing me from pressing buttons very easily. I know there is an interrupt() function, but with what I've researched thus far, you can only attach it to digital pins and the touch screen isn't dependent on one single pin.
IMHO, delay() exists only for a toddler to learn to blink a single LED. Any project bigger than that should stray away from delay().
You should learn the BlinkWithoutDelay sketch comes with the IDE to manage several things at the same time.
Thank you very much for an honest and fast reply! This has helped me a lot!
Take a look at Using millis() for timing. A beginners guide, Several things at the same time and look at the BlinkWithoutDelay example in the IDE.
"Welcome to chapter two of this Arduino tutorial. After we blinked a LED in chapter one, we'll continue in chapter two with: 'NOW NEVER USE DELAY AGAIN'." 
arduino_new:
IMHO, delay() exists only for a toddler to learn to blink a single LED
septillion:
NEVER USE DELAY AGAIN
Have either of you used the Playground's I2C EEPROM write function without putting the delay(5) on the end, as advocated (for example) by cattledog in #8 here? Would you bother writing that as delay()-less, millis()-based?
// below is the write function, untouched from playground, except ***
void i2c_eeprom_write_byte( int deviceaddress, unsigned int eeaddress, byte data ) {
int rdata = data;
Wire.beginTransmission(deviceaddress);
Wire.write((int)(eeaddress >> 8)); // MSB
Wire.write((int)(eeaddress & 0xFF)); // LSB
Wire.write(rdata);
Wire.endTransmission();
delay(5); //doesn't work without this ***
}
There are always exceptions that confirm the rule. Thing is, we should flip the thinking. Don't use delay() unless you are very sure you need it.
But even in this case, as long as you don't try to access the EEPROM again right away you are fine. So yeah, I would rather make smarter code around that than to use delay().
void readBytes(int device, unsigned int Address, byte len )
{
byte readBuffer[len];
Ouch 
Length of an array needs to be known at compiler time....
PS Did not read the complete 3 pages long topic.
septillion:
Don't use delay() unless you are very sure you need it.
Totally agree, and that's a point that many folk miss, when they take an Animal Farm-like binary approach to millis() good and delay() bad 
(I'd actually even add ", ... or understand and are prepared to suffer the possible consequences in silence."