Groups > comp.lang.javascript > #38935 > unrolled thread

Loop and move within boundary "interval logic for cursored list"

Started by	Jonas Thörnvall <jonas.thornvall@gmail.com>
First post	2020-10-13 13:46 -0700
Last post	2020-10-20 13:36 -0700
Articles	20 on this page of 53 — 5 participants

Back to article view | Back to comp.lang.javascript

  Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-13 13:46 -0700
    Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-13 14:01 -0700
    Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-13 14:09 -0700
      Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-13 15:05 -0700
        Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-13 18:07 -0700
          Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-13 18:22 -0700
            Re: Loop and move within boundary "interval logic for cursored list" luserdroog <luser.droog@gmail.com> - 2020-10-13 20:36 -0700
              Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-14 01:34 -0700
                Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-14 01:37 -0700
                  Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-14 01:38 -0700
                  Re: Loop and move within boundary "interval logic for cursored list" luserdroog <luser.droog@gmail.com> - 2020-10-14 10:51 -0700
                    Re: Loop and move within boundary "interval logic for cursored list" John G Harris <niam@jghnorth.org.uk.invalid> - 2020-10-15 18:03 +0100
                      Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-16 03:19 -0700
                        Re: Loop and move within boundary "interval logic for cursored list" John G Harris <niam@jghnorth.org.uk.invalid> - 2020-10-16 19:30 +0100
                          Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-16 12:36 -0700
                            Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-16 19:25 -0700
                Re: Loop and move within boundary "interval logic for cursored list" luserdroog <luser.droog@gmail.com> - 2020-10-14 10:32 -0700
              Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-14 02:32 -0700
                Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-14 02:40 -0700
              Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-14 05:05 -0700
                Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-14 05:16 -0700
            Re: Loop and move within boundary "interval logic for cursored list" John G Harris <niam@jghnorth.org.uk.invalid> - 2020-10-15 18:03 +0100
              Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-15 13:05 -0700
                Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-15 14:58 -0700
                Re: Loop and move within boundary "interval logic for cursored list" John G Harris <niam@jghnorth.org.uk.invalid> - 2020-10-16 19:14 +0100
                  Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-16 19:23 -0700
                    Re: Loop and move within boundary "interval logic for cursored list" "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-10-17 11:05 +0200
                      Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-17 03:07 -0700
                        Re: Loop and move within boundary "interval logic for cursored list" "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-10-17 14:47 +0200
                          Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-17 05:59 -0700
                            Re: Loop and move within boundary "interval logic for cursored list" "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-10-17 15:21 +0200
                          Re: Loop and move within boundary "interval logic for cursored list" John G Harris <niam@jghnorth.org.uk.invalid> - 2020-10-17 15:09 +0100
                            Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-17 11:11 -0700
                              Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-19 01:52 -0700
                                Re: Loop and move within boundary "interval logic for cursored list" "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-10-19 13:37 +0200
                                  Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-19 05:08 -0700
                                  Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-19 05:11 -0700
                                  Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-19 05:52 -0700
                                    Re: Loop and move within boundary "interval logic for cursored list" "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-10-19 19:15 +0200
                                      Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-19 11:01 -0700
                                        Re: Loop and move within boundary "interval logic for cursored list" "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-10-20 15:30 +0200
                                          Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-20 07:26 -0700
                                            Re: Loop and move within boundary "interval logic for cursored list" "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-10-21 00:01 +0200
                                              Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-20 18:19 -0700
                                                Re: Loop and move within boundary "interval logic for cursored list" "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-10-21 13:01 +0200
                                                  Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-21 15:07 -0700
                                                    Re: Loop and move within boundary "interval logic for cursored list" "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-10-22 01:21 +0200
                                          Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-20 07:31 -0700
                                Re: Loop and move within boundary "interval logic for cursored list" John G Harris <niam@jghnorth.org.uk.invalid> - 2020-10-19 18:04 +0100
                                  Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-19 10:47 -0700
                                    Re: Loop and move within boundary "interval logic for cursored list" John G Harris <niam@jghnorth.org.uk.invalid> - 2020-10-19 19:33 +0100
                                      Re: Loop and move within boundary "interval logic for cursored list" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-19 16:36 -0700
                                Re: Loop and move within boundary "interval logic for cursored list" Scott Sauyet <scott@sauyet.com> - 2020-10-20 13:36 -0700

Page 1 of 3 [1] 2 3 Next page →

#38935 — Loop and move within boundary "interval logic for cursored list"

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-13 13:46 -0700
Subject	Loop and move within boundary "interval logic for cursored list"
Message-ID	<3aa3cfef-d2c4-4108-9eb4-af4df1819619o@googlegroups.com>

I have a problem of writing out interval, it may be it actually need two loops to do what i want "could be but".

There is a list with items, named moveText with x row length. There is a cursor movenumber that "should be able to move within list". The max number of rows in moveText 41, so if it is bigger then 41, we have to move startpoint of list back by 41 seem logical. The following code below do that correct when move forward, and else we should start draw at element 0 because all elements fit in list. How ever using moveNumber the cursor as loop endpoint isn't ideal because you want to see all items "even those after cursor" when list is less then 41.

When list is less then 41 rows.

function drawTxtMove(){
	for (var i=drawStart;i<moveNumber;i++){
		ctm.fillStyle=tColor;
		ctm.font = "bold 17px serif";
		ctm.fillText(moveText[i], 9, 63+tSize);
		tSize=tSize+17;
		if(tSize>780){tSize=0;wSize=wSize+58;}
	}
	if (moveNumber>41) {drawStart=moveNumber-41;} else { drawStart=0;}
	tSize=0;
}

I had an idea, using some sort of extra term that switch between movenumber and moveText.length as delimiter for list depending on list length.

drawlimit=0;
function drawTxtMove(){
	for (var i=drawStart;i<drawlimit;i++){
		ctm.fillStyle=tColor;
		ctm.font = "bold 17px serif";
		ctm.fillText(moveText[i], 9, 63+tSize);
		tSize=tSize+17;
		if(tSize>780){tSize=0;wSize=wSize+58;}
	}
	if (moveText.length>41) {
			drawStart=moveNumber-41;
			drawlimit=moveNumber;
	} else { 
			drawStart=0;
			drawlimit=moveText.length;
	}
	tSize=0;
}

But for some reason when you back list and drawlimit becomes less then zero, drawatart some startrows become undefined

I thought i programmed when moveText.length<=42 drawStart should be 0, but apparently not. 

I must solved this type of problems 10th of times,but right now i just do not see what go wrong with boundary.

[toc] | [next] | [standalone]

#38936

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-13 14:01 -0700
Message-ID	<e6348536-a121-448c-8485-ecbfd783b1edo@googlegroups.com>
In reply to	#38935

Den tisdag 13 oktober 2020 kl. 22:46:42 UTC+2 skrev Jonas Thörnvall:
> I have a problem of writing out interval, it may be it actually need two loops to do what i want "could be but".
> 
> There is a list with items, named moveText with x row length. There is a cursor movenumber that "should be able to move within list". The max number of rows in moveText 41, so if it is bigger then 41, we have to move startpoint of list back by 41 seem logical. The following code below do that correct when move forward, and else we should start draw at element 0 because all elements fit in list. How ever using moveNumber the cursor as loop endpoint isn't ideal because you want to see all items "even those after cursor" when list is less then 41.
> 
> When list is less then 41 rows.
> 
> function drawTxtMove(){
> 	for (var i=drawStart;i<moveNumber;i++){
> 		ctm.fillStyle=tColor;
> 		ctm.font = "bold 17px serif";
> 		ctm.fillText(moveText[i], 9, 63+tSize);
> 		tSize=tSize+17;
> 		if(tSize>780){tSize=0;wSize=wSize+58;}
> 	}
> 	if (moveNumber>41) {drawStart=moveNumber-41;} else { drawStart=0;}
> 	tSize=0;
> }
> 
> I had an idea, using some sort of extra term that switch between movenumber and moveText.length as delimiter for list depending on list length.
> 
> drawlimit=0;
> function drawTxtMove(){
> 	for (var i=drawStart;i<drawlimit;i++){
> 		ctm.fillStyle=tColor;
> 		ctm.font = "bold 17px serif";
> 		ctm.fillText(moveText[i], 9, 63+tSize);
> 		tSize=tSize+17;
> 		if(tSize>780){tSize=0;wSize=wSize+58;}
> 	}
> 	if (moveText.length>41) {
> 			drawStart=moveNumber-41;
> 			drawlimit=moveNumber;
> 	} else { 
> 			drawStart=0;
> 			drawlimit=moveText.length;
> 	}
> 	tSize=0;
> }
> 
> But for some reason when you back list and drawlimit becomes less then zero, drawatart some startrows become undefined
> 
> I thought i programmed when moveText.length<=42 drawStart should be 0, but apparently not. 
> 
> I must solved this type of problems 10th of times,but right now i just do not see what go wrong with boundary.

For a brief moment i thought i solved it....
drawlimit=0;
function drawTxtMove(){
	//alert(moveText.length);
	ctm.fillStyle="#000066";
	ctm.fillRect(4,49,350,740);
	for (var i=drawStart;i<drawlimit;i++){
		if (i % 2 == 0){tColor="white";} else {tColor="black";}
		if (i % 2 == 0){bColor="grey";} else {bColor="lightgrey";}	
		ctm.fillStyle=bColor;
		if(moveNumber-1==i){ctm.fillStyle="orange";}
		ctm.fillRect(4,49+tSize,boardPos-116,16);
		ctm.fill();
		ctm.fillStyle=tColor;
		ctm.font = "bold 17px serif";
		ctm.fillText(moveText[i], 9, 63+tSize);
		tSize=tSize+17;
		if(tSize>780){tSize=0;wSize=wSize+58;}
	}
	if (moveText.length>41 && moveNumber>41) {
			drawStart=moveNumber-41;
			drawlimit=moveNumber;
	} else { 
			drawStart=0;
			drawlimit=moveText.length;
	}
	tSize=0;
}

[toc] | [prev] | [next] | [standalone]

#38937

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-13 14:09 -0700
Message-ID	<8e2aa158-51f5-4d3e-a3ae-c294442eaf74o@googlegroups.com>
In reply to	#38935

Den tisdag 13 oktober 2020 kl. 22:46:42 UTC+2 skrev Jonas Thörnvall:
> I have a problem of writing out interval, it may be it actually need two loops to do what i want "could be but".
> 
> There is a list with items, named moveText with x row length. There is a cursor movenumber that "should be able to move within list". The max number of rows in moveText 41, so if it is bigger then 41, we have to move startpoint of list back by 41 seem logical. The following code below do that correct when move forward, and else we should start draw at element 0 because all elements fit in list. How ever using moveNumber the cursor as loop endpoint isn't ideal because you want to see all items "even those after cursor" when list is less then 41.
> 
> When list is less then 41 rows.
> 
> function drawTxtMove(){
> 	for (var i=drawStart;i<moveNumber;i++){
> 		ctm.fillStyle=tColor;
> 		ctm.font = "bold 17px serif";
> 		ctm.fillText(moveText[i], 9, 63+tSize);
> 		tSize=tSize+17;
> 		if(tSize>780){tSize=0;wSize=wSize+58;}
> 	}
> 	if (moveNumber>41) {drawStart=moveNumber-41;} else { drawStart=0;}
> 	tSize=0;
> }
> 
> I had an idea, using some sort of extra term that switch between movenumber and moveText.length as delimiter for list depending on list length.
> 
> drawlimit=0;
> function drawTxtMove(){
> 	for (var i=drawStart;i<drawlimit;i++){
> 		ctm.fillStyle=tColor;
> 		ctm.font = "bold 17px serif";
> 		ctm.fillText(moveText[i], 9, 63+tSize);
> 		tSize=tSize+17;
> 		if(tSize>780){tSize=0;wSize=wSize+58;}
> 	}
> 	if (moveText.length>41) {
> 			drawStart=moveNumber-41;
> 			drawlimit=moveNumber;
> 	} else { 
> 			drawStart=0;
> 			drawlimit=moveText.length;
> 	}
> 	tSize=0;
> }
> 
> But for some reason when you back list and drawlimit becomes less then zero, drawatart some startrows become undefined
> 
> I thought i programmed when moveText.length<=42 drawStart should be 0, but apparently not. 
> 
> I must solved this type of problems 10th of times,but right now i just do not see what go wrong with boundary.

Solved but i can't imagine this is the easy way.

drawlimit=0;
function drawTxtMove(){
	//alert(moveText.length);
	ctm.fillStyle="#000066";
	ctm.fillRect(4,49,350,740);
	for (var i=drawStart;i<drawlimit;i++){
		ctm.fillStyle=tColor;
		ctm.font = "bold 17px serif";
		ctm.fillText(moveText[i], 9, 63+tSize);
		tSize=tSize+17;
		if(tSize>780){tSize=0;wSize=wSize+58;}
	}
	if (moveText.length>41 && moveNumber>41) {
			drawStart=moveNumber-41;
			drawlimit=moveNumber;
	} else { 
			drawStart=0;
	if (moveText.length<42){drawlimit=moveText.length} else {drawlimit=41;}
	}
	tSize=0;
}

[toc] | [prev] | [next] | [standalone]

#38938

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-13 15:05 -0700
Message-ID	<f6652595-e939-498d-b688-32c2dd6b76b2o@googlegroups.com>
In reply to	#38937

Den tisdag 13 oktober 2020 kl. 23:09:40 UTC+2 skrev Jonas Thörnvall:
> Den tisdag 13 oktober 2020 kl. 22:46:42 UTC+2 skrev Jonas Thörnvall:
> > I have a problem of writing out interval, it may be it actually need two loops to do what i want "could be but".
> > 
> > There is a list with items, named moveText with x row length. There is a cursor movenumber that "should be able to move within list". The max number of rows in moveText 41, so if it is bigger then 41, we have to move startpoint of list back by 41 seem logical. The following code below do that correct when move forward, and else we should start draw at element 0 because all elements fit in list. How ever using moveNumber the cursor as loop endpoint isn't ideal because you want to see all items "even those after cursor" when list is less then 41.
> > 
> > When list is less then 41 rows.
> > 
> > function drawTxtMove(){
> > 	for (var i=drawStart;i<moveNumber;i++){
> > 		ctm.fillStyle=tColor;
> > 		ctm.font = "bold 17px serif";
> > 		ctm.fillText(moveText[i], 9, 63+tSize);
> > 		tSize=tSize+17;
> > 		if(tSize>780){tSize=0;wSize=wSize+58;}
> > 	}
> > 	if (moveNumber>41) {drawStart=moveNumber-41;} else { drawStart=0;}
> > 	tSize=0;
> > }
> > 
> > I had an idea, using some sort of extra term that switch between movenumber and moveText.length as delimiter for list depending on list length.
> > 
> > drawlimit=0;
> > function drawTxtMove(){
> > 	for (var i=drawStart;i<drawlimit;i++){
> > 		ctm.fillStyle=tColor;
> > 		ctm.font = "bold 17px serif";
> > 		ctm.fillText(moveText[i], 9, 63+tSize);
> > 		tSize=tSize+17;
> > 		if(tSize>780){tSize=0;wSize=wSize+58;}
> > 	}
> > 	if (moveText.length>41) {
> > 			drawStart=moveNumber-41;
> > 			drawlimit=moveNumber;
> > 	} else { 
> > 			drawStart=0;
> > 			drawlimit=moveText.length;
> > 	}
> > 	tSize=0;
> > }
> > 
> > But for some reason when you back list and drawlimit becomes less then zero, drawatart some startrows become undefined
> > 
> > I thought i programmed when moveText.length<=42 drawStart should be 0, but apparently not. 
> > 
> > I must solved this type of problems 10th of times,but right now i just do not see what go wrong with boundary.
> 
> Solved but i can't imagine this is the easy way.
> 
> drawlimit=0;
> function drawTxtMove(){
> 	//alert(moveText.length);
> 	ctm.fillStyle="#000066";
> 	ctm.fillRect(4,49,350,740);
> 	for (var i=drawStart;i<drawlimit;i++){
> 		ctm.fillStyle=tColor;
> 		ctm.font = "bold 17px serif";
> 		ctm.fillText(moveText[i], 9, 63+tSize);
> 		tSize=tSize+17;
> 		if(tSize>780){tSize=0;wSize=wSize+58;}
> 	}
> 	if (moveText.length>41 && moveNumber>41) {
> 			drawStart=moveNumber-41;
> 			drawlimit=moveNumber;
> 	} else { 
> 			drawStart=0;
> 	if (moveText.length<42){drawlimit=moveText.length} else {drawlimit=41;}
> 	}
> 	tSize=0;
> }

Here try boundaries.
https://jonasth.github.io/chess/chess.html

[toc] | [prev] | [next] | [standalone]

#38939

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-13 18:07 -0700
Message-ID	<2a301664-d62c-459e-9df9-c0f02e20f208o@googlegroups.com>
In reply to	#38938

Den onsdag 14 oktober 2020 kl. 00:05:13 UTC+2 skrev Jonas Thörnvall:
> Den tisdag 13 oktober 2020 kl. 23:09:40 UTC+2 skrev Jonas Thörnvall:
> > Den tisdag 13 oktober 2020 kl. 22:46:42 UTC+2 skrev Jonas Thörnvall:
> > > I have a problem of writing out interval, it may be it actually need two loops to do what i want "could be but".
> > > 
> > > There is a list with items, named moveText with x row length. There is a cursor movenumber that "should be able to move within list". The max number of rows in moveText 41, so if it is bigger then 41, we have to move startpoint of list back by 41 seem logical. The following code below do that correct when move forward, and else we should start draw at element 0 because all elements fit in list. How ever using moveNumber the cursor as loop endpoint isn't ideal because you want to see all items "even those after cursor" when list is less then 41.
> > > 
> > > When list is less then 41 rows.
> > > 
> > > function drawTxtMove(){
> > > 	for (var i=drawStart;i<moveNumber;i++){
> > > 		ctm.fillStyle=tColor;
> > > 		ctm.font = "bold 17px serif";
> > > 		ctm.fillText(moveText[i], 9, 63+tSize);
> > > 		tSize=tSize+17;
> > > 		if(tSize>780){tSize=0;wSize=wSize+58;}
> > > 	}
> > > 	if (moveNumber>41) {drawStart=moveNumber-41;} else { drawStart=0;}
> > > 	tSize=0;
> > > }
> > > 
> > > I had an idea, using some sort of extra term that switch between movenumber and moveText.length as delimiter for list depending on list length.
> > > 
> > > drawlimit=0;
> > > function drawTxtMove(){
> > > 	for (var i=drawStart;i<drawlimit;i++){
> > > 		ctm.fillStyle=tColor;
> > > 		ctm.font = "bold 17px serif";
> > > 		ctm.fillText(moveText[i], 9, 63+tSize);
> > > 		tSize=tSize+17;
> > > 		if(tSize>780){tSize=0;wSize=wSize+58;}
> > > 	}
> > > 	if (moveText.length>41) {
> > > 			drawStart=moveNumber-41;
> > > 			drawlimit=moveNumber;
> > > 	} else { 
> > > 			drawStart=0;
> > > 			drawlimit=moveText.length;
> > > 	}
> > > 	tSize=0;
> > > }
> > > 
> > > But for some reason when you back list and drawlimit becomes less then zero, drawatart some startrows become undefined
> > > 
> > > I thought i programmed when moveText.length<=42 drawStart should be 0, but apparently not. 
> > > 
> > > I must solved this type of problems 10th of times,but right now i just do not see what go wrong with boundary.
> > 
> > Solved but i can't imagine this is the easy way.
> > 
> > drawlimit=0;
> > function drawTxtMove(){
> > 	//alert(moveText.length);
> > 	ctm.fillStyle="#000066";
> > 	ctm.fillRect(4,49,350,740);
> > 	for (var i=drawStart;i<drawlimit;i++){
> > 		ctm.fillStyle=tColor;
> > 		ctm.font = "bold 17px serif";
> > 		ctm.fillText(moveText[i], 9, 63+tSize);
> > 		tSize=tSize+17;
> > 		if(tSize>780){tSize=0;wSize=wSize+58;}
> > 	}
> > 	if (moveText.length>41 && moveNumber>41) {
> > 			drawStart=moveNumber-41;
> > 			drawlimit=moveNumber;
> > 	} else { 
> > 			drawStart=0;
> > 	if (moveText.length<42){drawlimit=moveText.length} else {drawlimit=41;}
> > 	}
> > 	tSize=0;
> > }
> 
> Here try boundaries.
> https://jonasth.github.io/chess/chess.html

Still not working just notice i am one move behind.

[toc] | [prev] | [next] | [standalone]

#38940

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-13 18:22 -0700
Message-ID	<3990d6cd-81b1-4a9e-ac00-0508f99c514eo@googlegroups.com>
In reply to	#38939

Den onsdag 14 oktober 2020 kl. 03:07:33 UTC+2 skrev Jonas Thörnvall:
> Den onsdag 14 oktober 2020 kl. 00:05:13 UTC+2 skrev Jonas Thörnvall:
> > Den tisdag 13 oktober 2020 kl. 23:09:40 UTC+2 skrev Jonas Thörnvall:
> > > Den tisdag 13 oktober 2020 kl. 22:46:42 UTC+2 skrev Jonas Thörnvall:
> > > > I have a problem of writing out interval, it may be it actually need two loops to do what i want "could be but".
> > > > 
> > > > There is a list with items, named moveText with x row length. There is a cursor movenumber that "should be able to move within list". The max number of rows in moveText 41, so if it is bigger then 41, we have to move startpoint of list back by 41 seem logical. The following code below do that correct when move forward, and else we should start draw at element 0 because all elements fit in list. How ever using moveNumber the cursor as loop endpoint isn't ideal because you want to see all items "even those after cursor" when list is less then 41.
> > > > 
> > > > When list is less then 41 rows.
> > > > 
> > > > function drawTxtMove(){
> > > > 	for (var i=drawStart;i<moveNumber;i++){
> > > > 		ctm.fillStyle=tColor;
> > > > 		ctm.font = "bold 17px serif";
> > > > 		ctm.fillText(moveText[i], 9, 63+tSize);
> > > > 		tSize=tSize+17;
> > > > 		if(tSize>780){tSize=0;wSize=wSize+58;}
> > > > 	}
> > > > 	if (moveNumber>41) {drawStart=moveNumber-41;} else { drawStart=0;}
> > > > 	tSize=0;
> > > > }
> > > > 
> > > > I had an idea, using some sort of extra term that switch between movenumber and moveText.length as delimiter for list depending on list length.
> > > > 
> > > > drawlimit=0;
> > > > function drawTxtMove(){
> > > > 	for (var i=drawStart;i<drawlimit;i++){
> > > > 		ctm.fillStyle=tColor;
> > > > 		ctm.font = "bold 17px serif";
> > > > 		ctm.fillText(moveText[i], 9, 63+tSize);
> > > > 		tSize=tSize+17;
> > > > 		if(tSize>780){tSize=0;wSize=wSize+58;}
> > > > 	}
> > > > 	if (moveText.length>41) {
> > > > 			drawStart=moveNumber-41;
> > > > 			drawlimit=moveNumber;
> > > > 	} else { 
> > > > 			drawStart=0;
> > > > 			drawlimit=moveText.length;
> > > > 	}
> > > > 	tSize=0;
> > > > }
> > > > 
> > > > But for some reason when you back list and drawlimit becomes less then zero, drawatart some startrows become undefined
> > > > 
> > > > I thought i programmed when moveText.length<=42 drawStart should be 0, but apparently not. 
> > > > 
> > > > I must solved this type of problems 10th of times,but right now i just do not see what go wrong with boundary.
> > > 
> > > Solved but i can't imagine this is the easy way.
> > > 
> > > drawlimit=0;
> > > function drawTxtMove(){
> > > 	//alert(moveText.length);
> > > 	ctm.fillStyle="#000066";
> > > 	ctm.fillRect(4,49,350,740);
> > > 	for (var i=drawStart;i<drawlimit;i++){
> > > 		ctm.fillStyle=tColor;
> > > 		ctm.font = "bold 17px serif";
> > > 		ctm.fillText(moveText[i], 9, 63+tSize);
> > > 		tSize=tSize+17;
> > > 		if(tSize>780){tSize=0;wSize=wSize+58;}
> > > 	}
> > > 	if (moveText.length>41 && moveNumber>41) {
> > > 			drawStart=moveNumber-41;
> > > 			drawlimit=moveNumber;
> > > 	} else { 
> > > 			drawStart=0;
> > > 	if (moveText.length<42){drawlimit=moveText.length} else {drawlimit=41;}
> > > 	}
> > > 	tSize=0;
> > > }
> > 
> > Here try boundaries.
> > https://jonasth.github.io/chess/chess.html
> 
> Still not working just notice i am one move behind.

I think i can see what fuck it up "had to revert to simple solution without full listing" the index of movenumber and moveText.length is not same and that make it nearly impossible to position yourself without changing move forward and backward.

The idiots who once decided that first element in an array is zero....
They caused billions of bugs in thousands programming languages.

[toc] | [prev] | [next] | [standalone]

#38941

From	luserdroog <luser.droog@gmail.com>
Date	2020-10-13 20:36 -0700
Message-ID	<04b96400-1083-4aad-a123-9e5def8258f7o@googlegroups.com>
In reply to	#38940

On Tuesday, October 13, 2020 at 8:22:59 PM UTC-5, Jonas Thörnvall wrote:

> I think i can see what fuck it up "had to revert to simple solution without full listing" the index of movenumber and moveText.length is not same and that make it nearly impossible to position yourself without changing move forward and backward.
> 
> The idiots who once decided that first element in an array is zero....
> They caused billions of bugs in thousands programming languages.

In APL arrays were originally based on one.
Then they made it configurable... and finally settled on mostly zero,
but still configurable. 

Zero is common enough that it's probably best to get used to it.

[toc] | [prev] | [next] | [standalone]

#38942

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-14 01:34 -0700
Message-ID	<59bc18da-f980-4f6d-8100-74a8300b5f54o@googlegroups.com>
In reply to	#38941

Den onsdag 14 oktober 2020 kl. 05:36:57 UTC+2 skrev luserdroog:
> On Tuesday, October 13, 2020 at 8:22:59 PM UTC-5, Jonas Thörnvall wrote:
> 
> > I think i can see what fuck it up "had to revert to simple solution without full listing" the index of movenumber and moveText.length is not same and that make it nearly impossible to position yourself without changing move forward and backward.
> > 
> > The idiots who once decided that first element in an array is zero....
> > They caused billions of bugs in thousands programming languages.
> 
> In APL arrays were originally based on one.
> Then they made it configurable... and finally settled on mostly zero,
> but still configurable. 
> 
> Zero is common enough that it's probably best to get used to it.

What is the historical justification for coming up with that a in set?/array with 1 element the first  element is "named?/indexed" zero. Dud it save a bit?

I can't come up with any real life situation where you would like the first event to be event zero? Or first object?

Maybe physics of time keeping, one do call first event zero T0, but it hardly make any sense because it always time zero?

I can see though that it probably have to do something with early computers.

[toc] | [prev] | [next] | [standalone]

#38943

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-14 01:37 -0700
Message-ID	<a671e1fd-b304-4815-8411-762c38dda11fo@googlegroups.com>
In reply to	#38942

Den onsdag 14 oktober 2020 kl. 10:34:43 UTC+2 skrev Jonas Thörnvall:
> Den onsdag 14 oktober 2020 kl. 05:36:57 UTC+2 skrev luserdroog:
> > On Tuesday, October 13, 2020 at 8:22:59 PM UTC-5, Jonas Thörnvall wrote:
> > 
> > > I think i can see what fuck it up "had to revert to simple solution without full listing" the index of movenumber and moveText.length is not same and that make it nearly impossible to position yourself without changing move forward and backward.
> > > 
> > > The idiots who once decided that first element in an array is zero....
> > > They caused billions of bugs in thousands programming languages.
> > 
> > In APL arrays were originally based on one.
> > Then they made it configurable... and finally settled on mostly zero,
> > but still configurable. 
> > 
> > Zero is common enough that it's probably best to get used to it.
> 
> What is the historical justification for coming up with that a in set?/array with 1 element the first  element is "named?/indexed" zero. Dud it save a bit?
> 
> I can't come up with any real life situation where you would like the first event to be event zero? Or first object?
> 
> Maybe physics of time keeping, one do call first event zero T0, but it hardly make any sense because it always time zero?
> 
> I can see though that it probably have to do something with early computers.

If you decided on first element being  indexed zero, would it not been consistent to say that an array that have 1 element, is of length zero????

[toc] | [prev] | [next] | [standalone]

#38944

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-14 01:38 -0700
Message-ID	<eddaaf02-b764-4892-9e42-41a69bca16f1o@googlegroups.com>
In reply to	#38943

Den onsdag 14 oktober 2020 kl. 10:37:16 UTC+2 skrev Jonas Thörnvall:
> Den onsdag 14 oktober 2020 kl. 10:34:43 UTC+2 skrev Jonas Thörnvall:
> > Den onsdag 14 oktober 2020 kl. 05:36:57 UTC+2 skrev luserdroog:
> > > On Tuesday, October 13, 2020 at 8:22:59 PM UTC-5, Jonas Thörnvall wrote:
> > > 
> > > > I think i can see what fuck it up "had to revert to simple solution without full listing" the index of movenumber and moveText.length is not same and that make it nearly impossible to position yourself without changing move forward and backward.
> > > > 
> > > > The idiots who once decided that first element in an array is zero....
> > > > They caused billions of bugs in thousands programming languages.
> > > 
> > > In APL arrays were originally based on one.
> > > Then they made it configurable... and finally settled on mostly zero,
> > > but still configurable. 
> > > 
> > > Zero is common enough that it's probably best to get used to it.
> > 
> > What is the historical justification for coming up with that a in set?/array with 1 element the first  element is "named?/indexed" zero. Dud it save a bit?
> > 
> > I can't come up with any real life situation where you would like the first event to be event zero? Or first object?
> > 
> > Maybe physics of time keeping, one do call first event zero T0, but it hardly make any sense because it always time zero?
> > 
> > I can see though that it probably have to do something with early computers.
> 
> If you decided on first element being  indexed zero, would it not been consistent to say that an array that have 1 element, is of length zero????

Yeah i know it is idiotic, but at least then there is some system to the idiocies...

[toc] | [prev] | [next] | [standalone]

#38950

From	luserdroog <luser.droog@gmail.com>
Date	2020-10-14 10:51 -0700
Message-ID	<dc11e5ab-1fb1-4ba0-9637-79d98cecf567o@googlegroups.com>
In reply to	#38943

On Wednesday, October 14, 2020 at 3:37:16 AM UTC-5, Jonas Thörnvall wrote:
> Den onsdag 14 oktober 2020 kl. 10:34:43 UTC+2 skrev Jonas Thörnvall:
> > Den onsdag 14 oktober 2020 kl. 05:36:57 UTC+2 skrev luserdroog:
> > > On Tuesday, October 13, 2020 at 8:22:59 PM UTC-5, Jonas Thörnvall wrote:
> > > 
> > > > I think i can see what fuck it up "had to revert to simple solution without full listing" the index of movenumber and moveText.length is not same and that make it nearly impossible to position yourself without changing move forward and backward.
> > > > 
> > > > The idiots who once decided that first element in an array is zero....
> > > > They caused billions of bugs in thousands programming languages.
> > > 
> > > In APL arrays were originally based on one.
> > > Then they made it configurable... and finally settled on mostly zero,
> > > but still configurable. 
> > > 
> > > Zero is common enough that it's probably best to get used to it.
> > 
> > What is the historical justification for coming up with that a in set?/array with 1 element the first  element is "named?/indexed" zero. Dud it save a bit?
> > 
> > I can't come up with any real life situation where you would like the first event to be event zero? Or first object?
> > 
> > Maybe physics of time keeping, one do call first event zero T0, but it hardly make any sense because it always time zero?
> > 
> > I can see though that it probably have to do something with early computers.
> 
> If you decided on first element being  indexed zero, would it not been consistent to say that an array that have 1 element, is of length zero????

I think a better way to think about it is to separate the two
concepts of Ordinal numbers and Cardinal numbers.

If you consider Cardinal numbers to count "things" then it's natural
to start at one.

If you consider Ordinal numbers to count "spaces", then it's natural
to start at zero. The magic is that the difference between two
Ordinal numbers will tell you how many Cardinal things will fit
in the space in the middle.

0:
   A1
1:
   A2
2:
   A3
3:

[toc] | [prev] | [next] | [standalone]

#38955

From	John G Harris <niam@jghnorth.org.uk.invalid>
Date	2020-10-15 18:03 +0100
Message-ID	<633gof94s5487niksh4a17008qddk5l201@4ax.com>
In reply to	#38950

On Wed, 14 Oct 2020 10:51:30 -0700 (PDT), luserdroog
<luser.droog@gmail.com> wrote:

  <snip>
>If you consider Cardinal numbers to count "things" then it's natural
>to start at one.
  <snip>

Ask a farmer how many cows he has in his 10 acre field. He can't say
none, aka zero, because zero is not an answer to 'how many' ?

I disagree. All counting starts at zero :
  no cows, one cow, two cows, ...
as they are led into the field.

It's the peculiarities of human languages that make zero seem to be
excluded.

  John

[toc] | [prev] | [next] | [standalone]

#38959

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-16 03:19 -0700
Message-ID	<bf78cc41-0a49-44c7-aadf-e894eb31516ao@googlegroups.com>
In reply to	#38955

Den torsdag 15 oktober 2020 kl. 19:03:28 UTC+2 skrev John G Harris:
> On Wed, 14 Oct 2020 10:51:30 -0700 (PDT), luserdroog
> <luser.droog@gmail.com> wrote:
> 
>   <snip>
> >If you consider Cardinal numbers to count "things" then it's natural
> >to start at one.
>   <snip>
> 
> Ask a farmer how many cows he has in his 10 acre field. He can't say
> none, aka zero, because zero is not an answer to 'how many' ?
> 
> I disagree. All counting starts at zero :
>   no cows, one cow, two cows, ...
> as they are led into the field.

But if counting start at zero does that really mean that zero should hold a cow? Or event, isn't it only "a pointer" to positon yourself but holding no value.
 
> It's the peculiarities of human languages that make zero seem to be
> excluded.
> 
>   John

[toc] | [prev] | [next] | [standalone]

#38961

From	John G Harris <niam@jghnorth.org.uk.invalid>
Date	2020-10-16 19:30 +0100
Message-ID	<8ipjoflqi4ah19ac5t2kbprel58lp511jb@4ax.com>
In reply to	#38959

On Fri, 16 Oct 2020 03:19:37 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

  <snip>
>> I disagree. All counting starts at zero :
>>   no cows, one cow, two cows, ...
>> as they are led into the field.
>
>But if counting start at zero does that really mean that zero should hold a cow? 

Counting tells you how many there are, and zero is a possible number.
'Holding' has nothing to do with counting.

>Or event, isn't it only "a pointer" to positon yourself but holding no value.
  <snip>

ECMAScript allows the array indexes to start at any number you like
(>= 0). You can choose 0 or 1 or 7 or 13 or ... , and indexes don't
have to be consecutive numbers.

Of course, if you can't remember what index numbers you a using for
each array then you will get into trouble, and thoroughly deserve to.

  John

[toc] | [prev] | [next] | [standalone]

#38962

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-16 12:36 -0700
Message-ID	<0c5213e8-a26a-4efa-bc91-030ea4c2002do@googlegroups.com>
In reply to	#38961

Den fredag 16 oktober 2020 kl. 20:30:21 UTC+2 skrev John G Harris:
> On Fri, 16 Oct 2020 03:19:37 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
> >> I disagree. All counting starts at zero :
> >>   no cows, one cow, two cows, ...
> >> as they are led into the field.
> >
> >But if counting start at zero does that really mean that zero should hold a cow? 
> 
> Counting tells you how many there are, and zero is a possible number.
> 'Holding' has nothing to do with counting.
> 
> 
> >Or event, isn't it only "a pointer" to positon yourself but holding no value.
>   <snip>
> 
> ECMAScript allows the array indexes to start at any number you like
> (>= 0). You can choose 0 or 1 or 7 or 13 or ... , and indexes don't
> have to be consecutive numbers.
> 
> Of course, if you can't remember what index numbers you a using for
> each array then you will get into trouble, and thoroughly deserve to.
> 
>   John

Counting isn't math more then diddle, doddle, daddle, cat, fish, dog

[toc] | [prev] | [next] | [standalone]

#38965

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-16 19:25 -0700
Message-ID	<1bff5a90-b570-4aea-b307-1d5cf6876be0o@googlegroups.com>
In reply to	#38962

Den fredag 16 oktober 2020 kl. 21:36:28 UTC+2 skrev Jonas Thörnvall:
> Den fredag 16 oktober 2020 kl. 20:30:21 UTC+2 skrev John G Harris:
> > On Fri, 16 Oct 2020 03:19:37 -0700 (PDT), Jonas Thörnvall
> > <jonas.thornvall@gmail.com> wrote:
> > 
> >   <snip>
> > >> I disagree. All counting starts at zero :
> > >>   no cows, one cow, two cows, ...
> > >> as they are led into the field.
> > >
> > >But if counting start at zero does that really mean that zero should hold a cow? 
> > 
> > Counting tells you how many there are, and zero is a possible number.
> > 'Holding' has nothing to do with counting.
> > 
> > 
> > >Or event, isn't it only "a pointer" to positon yourself but holding no value.
> >   <snip>
> > 
> > ECMAScript allows the array indexes to start at any number you like
> > (>= 0). You can choose 0 or 1 or 7 or 13 or ... , and indexes don't
> > have to be consecutive numbers.
> > 
> > Of course, if you can't remember what index numbers you a using for
> > each array then you will get into trouble, and thoroughly deserve to.
> > 
> >   John
> 
> Counting isn't math more then diddle, doddle, daddle, cat, fish, dog

Counting is just the sloppy term for add one that we do implicit, without it 1,2,3 is just a sequence of symbols.

[toc] | [prev] | [next] | [standalone]

#38949

From	luserdroog <luser.droog@gmail.com>
Date	2020-10-14 10:32 -0700
Message-ID	<1374a73d-afa0-4505-b41e-60bdc7cb39a3o@googlegroups.com>
In reply to	#38942

On Wednesday, October 14, 2020 at 3:34:43 AM UTC-5, Jonas Thörnvall wrote:
> Den onsdag 14 oktober 2020 kl. 05:36:57 UTC+2 skrev luserdroog:
> > On Tuesday, October 13, 2020 at 8:22:59 PM UTC-5, Jonas Thörnvall wrote:
> > 
> > > I think i can see what fuck it up "had to revert to simple solution without full listing" the index of movenumber and moveText.length is not same and that make it nearly impossible to position yourself without changing move forward and backward.
> > > 
> > > The idiots who once decided that first element in an array is zero....
> > > They caused billions of bugs in thousands programming languages.
> > 
> > In APL arrays were originally based on one.
> > Then they made it configurable... and finally settled on mostly zero,
> > but still configurable. 
> > 
> > Zero is common enough that it's probably best to get used to it.
> 
> What is the historical justification for coming up with that a in set?/array with 1 element the first  element is "named?/indexed" zero. Dud it save a bit?
> 
> I can't come up with any real life situation where you would like the first event to be event zero? Or first object?
> 
> Maybe physics of time keeping, one do call first event zero T0, but it hardly make any sense because it always time zero?
> 
> I can see though that it probably have to do something with early computers.

It came up on early computers but it's still relevant for modern 
architectures. Say you have an array of integers in memory at 
address 500,

  500:   int1  int2  int3  ...

If you have the address of the array somewhere, in a sense it 
already is the address of the first element. So, in early languages
like C the array access formula was designed to be:

  a[i] == *(a + i)

It wouldn't be very difficult to start from 1, but it would be
less efficient.

  base=1
  a[i] == *(a - base + i)

Now you can start with one. But to use the array, you're just going
to be subtracting off that one every time you access an element.

[toc] | [prev] | [next] | [standalone]

#38945

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-14 02:32 -0700
Message-ID	<bac5a20e-3809-4eda-ab38-22044d94ef2eo@googlegroups.com>
In reply to	#38941

Den onsdag 14 oktober 2020 kl. 05:36:57 UTC+2 skrev luserdroog:
> On Tuesday, October 13, 2020 at 8:22:59 PM UTC-5, Jonas Thörnvall wrote:
> 
> > I think i can see what fuck it up "had to revert to simple solution without full listing" the index of movenumber and moveText.length is not same and that make it nearly impossible to position yourself without changing move forward and backward.
> > 
> > The idiots who once decided that first element in an array is zero....
> > They caused billions of bugs in thousands programming languages.
> 
> In APL arrays were originally based on one.
> Then they made it configurable... and finally settled on mostly zero,
> but still configurable. 
> 
> Zero is common enough that it's probably best to get used to it.

"I think" i solved it after debugin the variables, i realised it was not the index that fuck up, it was the order i did things.

function drawTxtMove(){
	if (moveText.length>41 && moveNumber>41) {
			drawStart=moveNumber-41;
			drawLimit=moveNumber;
	} else { 
			drawStart=0;
			if (moveText.length<42){drawLimit=moveText.length; console.log(drawLimit);} else {drawLimit=42;}
	}
	ctm.fillStyle="#000066";
	ctm.fillRect(4,49,350,940);
	for (var i=drawStart;i<drawLimit;i++){
		if (i % 2 == 0){tColor="white";} else {tColor="black";}
		if (i % 2 == 0){bColor="grey";} else {bColor="lightgrey";}	
		ctm.fillStyle=bColor;
		if(moveNumber-1==i){ctm.fillStyle="orange";}
		ctm.fillRect(4,49+tSize,boardPos-116,16);
		ctm.fill();
		ctm.fillStyle=tColor;
		ctm.font = "bold 17px serif";
		ctm.fillText(moveText[i], 9, 63+tSize);
		tSize=tSize+17;
		if(tSize>780){tSize=0;wSize=wSize+58;}
		txtLoop=i;
	}
	tSize=0;
}

[toc] | [prev] | [next] | [standalone]

#38946

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-14 02:40 -0700
Message-ID	<ba08934f-1b99-4f21-824f-e4b4aeb58b56o@googlegroups.com>
In reply to	#38945

Den onsdag 14 oktober 2020 kl. 11:32:44 UTC+2 skrev Jonas Thörnvall:
> Den onsdag 14 oktober 2020 kl. 05:36:57 UTC+2 skrev luserdroog:
> > On Tuesday, October 13, 2020 at 8:22:59 PM UTC-5, Jonas Thörnvall wrote:
> > 
> > > I think i can see what fuck it up "had to revert to simple solution without full listing" the index of movenumber and moveText.length is not same and that make it nearly impossible to position yourself without changing move forward and backward.
> > > 
> > > The idiots who once decided that first element in an array is zero....
> > > They caused billions of bugs in thousands programming languages.
> > 
> > In APL arrays were originally based on one.
> > Then they made it configurable... and finally settled on mostly zero,
> > but still configurable. 
> > 
> > Zero is common enough that it's probably best to get used to it.
> 
> "I think" i solved it after debugin the variables, i realised it was not the index that fuck up, it was the order i did things.
> 
> function drawTxtMove(){
> 	if (moveText.length>41 && moveNumber>41) {
> 			drawStart=moveNumber-41;
> 			drawLimit=moveNumber;
> 	} else { 
> 			drawStart=0;
> 			if (moveText.length<42){drawLimit=moveText.length; console.log(drawLimit);} else {drawLimit=42;}
> 	}
> 	ctm.fillStyle="#000066";
> 	ctm.fillRect(4,49,350,940);
> 	for (var i=drawStart;i<drawLimit;i++){
> 		if (i % 2 == 0){tColor="white";} else {tColor="black";}
> 		if (i % 2 == 0){bColor="grey";} else {bColor="lightgrey";}	
> 		ctm.fillStyle=bColor;
> 		if(moveNumber-1==i){ctm.fillStyle="orange";}
> 		ctm.fillRect(4,49+tSize,boardPos-116,16);
> 		ctm.fill();
> 		ctm.fillStyle=tColor;
> 		ctm.font = "bold 17px serif";
> 		ctm.fillText(moveText[i], 9, 63+tSize);
> 		tSize=tSize+17;
> 		if(tSize>780){tSize=0;wSize=wSize+58;}
> 		txtLoop=i;
> 	}
> 	tSize=0;
> }

Does the solution look reasonable?

[toc] | [prev] | [next] | [standalone]

#38947

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2020-10-14 05:05 -0700
Message-ID	<af84dd76-db84-4ea4-ba94-75dba0874d08o@googlegroups.com>
In reply to	#38941

Den onsdag 14 oktober 2020 kl. 05:36:57 UTC+2 skrev luserdroog:
> On Tuesday, October 13, 2020 at 8:22:59 PM UTC-5, Jonas Thörnvall wrote:
> 
> > I think i can see what fuck it up "had to revert to simple solution without full listing" the index of movenumber and moveText.length is not same and that make it nearly impossible to position yourself without changing move forward and backward.
> > 
> > The idiots who once decided that first element in an array is zero....
> > They caused billions of bugs in thousands programming languages.
> 
> In APL arrays were originally based on one.
> Then they made it configurable... and finally settled on mostly zero,
> but still configurable. 
> 
> Zero is common enough that it's probably best to get used to it.

Further thoughts on indexes, it seem unavoidable that index zero must exist to position yourself before something start, it is questionable if one should allow it to hold a value though. So you can position yourself at index zero but as soon you start to push things in to array they will start at index one.

The whole thing with start and end seem a pretty weird and lose concepts, is start before the first element or is start the first element. It seem we could have a list but not selected any of its element, so zero seem necessary in an array index???

But i do not think it "should" hold any data?

[toc] | [prev] | [next] | [standalone]

Page 1 of 3 [1] 2 3 Next page →

csiph-web

Loop and move within boundary "interval logic for cursored list"

Contents

#38935 — Loop and move within boundary "interval logic for cursored list"

#38936

#38937

#38938

#38939

#38940

#38941

#38942

#38943

#38944

#38950

#38955

#38959

#38961

#38962

#38965

#38949

#38945

#38946

#38947