Are for-loops not allowed in callback functions?

Started by
12 comments, last by Wyrframe 7 years, 1 month ago

[Edit: Never mind ... a very dumb post from me, .... had been coding 16 hours straight everyday for several weeks and that took its toll on me]

I got some crashes and started investigating. It boiled down to the loop in my callback function not being called as expected.

I don't know what's really going on anymore, are loops not allowed in callback functions or am i doing something seriously retarded and just can't see it

This code doesn't even get inside the for-loop and i just don't understand why. ... > && <= should get into the loop

Anyone knows whats happening?

Java/Android and while the basics and logic remain intact, much of this code is simplified so it can be understood


    char charToIntArry[];
    int u=0;
	@Override
 	protected void onActivityResult(int requestCode, int resultCode, Intent data) {
		switch(requestCode){
	     	case PICKFILE_RESULT_CODE:
	     		if(resultCode==RESULT_OK){
	     			...
                                ...
	     			Log.v(tag,  "(Path.length()-5)   "+((Path.length()-5)));
	     			charToIntArry = new char[((Path.length()-5)-44)];

	     			for(u=0; u<(filePath.length()-5) ; u++){   //dynamic but simplified to static values 
	     				if((u>44)&&(u<=(filePath.length()-5))){
                                              //Log.v(tag,  "(Path.length()-5)-44    "+((Path.length()-5)-44)+"  u  "+u+"  Path.charAt(u)   "+Path.charAt(u) );
	     				      charToIntArry[u] = Path.charAt(u);
                                      }
	     			}
	     		        ...
	     			...
	     			Log.v(tag,  "u  "+u );  // u remains at 0 (see output)
		     		...
                                ...
	     		}
	     		break;	   
		 }
 	}

output completely misses the loop


V/tag    : (Path.length()-5)   47
V/tag    : u  0

can't help being grumpy...

Just need to let some steam out, so my head doesn't explode...

Advertisement

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.

"Errare humanum est, sed in errare perseverare diabolicum."

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

can't help being grumpy...

Just need to let some steam out, so my head doesn't explode...

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);
    }
} 

can't help being grumpy...

Just need to let some steam out, so my head doesn't explode...

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?

can't help being grumpy...

Just need to let some steam out, so my head doesn't explode...

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

can't help being grumpy...

Just need to let some steam out, so my head doesn't explode...

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

This topic is closed to new replies.

Advertisement