Are for-loops not allowed in callback functions?

for(u=0; ((u>44)&&(u<=47)); u++){

The for loop will never execute because the first condition is always false. 0 > 44 is false.

The for loop will never execute because the first condition is always false. 0 > 44 is false.

LATE EDIT: yeah, I have been very retarded and dumb :( due to my fatigue from very long hours. ... my bad,

probably need some long break

But u won't be increasing. The first time through the loop, it checks to see if u>44 and since it's not, it terminates the loop.

Right, I somehow thought it might get to this. YES I HAVE BEEN DOING SOMETHING VERY RETARDED, NOW I'M SERIOUSLY EMBARRASSED :( :( :(

code should be like this

for(u=0; u<filePath.length() ; u++){
    if((u>44)&&(u<=47)){	     				
         Log.v(tag,  "(filePath.length()-5)-44    "+((filePath.length()-5)-44)+"  u  "+u+"  filePath.charAt(u)   "+filePath.charAt(u) );
         //charToIntArry[u] = filePath.charAt(u);
    }
} 

Why not just use

for(u=45; u<=47; ++u)

?

Why not just use

for(u=45; u<=47; ++u)

?

in simple loops such as this, is there any difference between pre-increment and post-increment?

No practical difference. Possibly some slightly different code generation on the back end (pre-increment doesn't require a temporary, since it's assumed you don't need the pre-increment value of u), but I reckon most compilers are smart enough to deduce your usage even with post-increment, and really in a loop such as this the differences in any case would be irrelevant.

Why not just use

for(u=45; u<=47; ++u)

?

I was hasty while reading the quoted post, so i thought you were only pointing out the pre-increment/post-increment difference in your suggestion. Now I also notice the loop hard-coding...

I couldn't hard-code the loop like that because i only hard-coded the top to 47 temporarily when i started looking for (my dumb) crash point. I could hard code the start to 44 though becuase the start is always the same - it cuts out chars in blue in the filepath like /storage/emulated/0/folder0/folder2/xxxx00003465.jpg

But 3465 could change from single digit to multiple digits and thats the chars i want to filter out and convert to integer

so more correctly it should be:

for(u=45; u<(filePath.length()-5) ; u++){              // -5 to cut out ".jpg"
     if((u>44)&&(u<=(filePath.length()-5))){
	     	charToIntArry[u] = filePath.charAt(u);	     				
     }
}

^

^

Bloody hell!!! i can't even read well, i'm working myself down- really need a break

Offsets and indices are more difficult than you think. I often use a piece of paper or a white-board, and make an example (a list of boxes with letters, in your case), with index values written above them, and arrows pointing at all the relevant spots.

Then I write the code, and check with the example how it will run, and whether all my offsets and length calculations are actually correct.

Another solution is not to hard-code things, but let the computer find the key-indices in the problem. For you, let the machine find the last "." and the last "x", and it gives you the area of interest, without magic counting from you. Takes a few micro-seconds, but these devices are never wrong :p

It sounds like you want to check for some condition every iteration and use the continue statement to skip your for-loop logic. Or you could use a previous for-loop to determine the index to start at.

For you, let the machine find the last "." and the last "x", and it gives you the area of interest, without magic counting from you. Takes a few micro-seconds, but these devices are never wrong :p

This. ???
It's called string splitting with delimiter.

if(resultCode==RESULT_OK){
//[...]
  int fileID = -1;
  int lastSlash = filePath.lastIndexOf('/');
  int extension = filePath.indexOf('.', lastSlash);

  if( extension > lastSlash ) {
    fileID = 0;
    for(int i = lastSlash + 1; i < extension; ++i) {
      char e = filePath.charAt(i);
      if( e >= '0' && e <= '9' ) {
        fileID = fileID * 10 + e - '0';
      }
    }
  }

  // If fileID is still -1, the path didn't end in a numerically-suffixed file.

//[...]
}

Lower cost than RegExp matching the file for the numeric part, but mind that it falls over if your terminal filename has multiple numeric sections (e.g. "photo-2017-01-02-000003456.jpg"); it treats all digits in the terminal filename as being part of the ID. No length assumptions (except that the file ID will fit in a 32-bit int), no spurious char[] or int[] allocation.