Oh, boy, am I in trouble. I'm one of those people who has used the terms pretty much interchangeably. Now I'm going to have to go back and rewrite all my code.
I may be missing some blatently obvious sarcasm, but what would you have to re-write? It's just semantics.
Ok, I'm back! Long week of work. Non-amx-related, unfortunately.
Back to multi-dimensional arrays:
I understand the concept of 2-dimensional and 3-dimensional arrays, which is what John used for the example above. I get that a multi-dimensional array (sElementstoParse)was used in order to store each search string type. Makes sense to me, in that the array can be searched easier as it is better organized. John, what is the purpose of making the array a size of [16][30], as opposed to [8][30], which would fit the 8 elements? Was that just a quickly-sized array so that you knew there was going to be enough space, or is there something else I'm missing with that? If so, does the same hold true for the sWeatherElements array?
Ok, I'm back! Long week of work. Non-amx-related, unfortunately.
Back to multi-dimensional arrays:
I understand the concept of 2-dimensional and 3-dimensional arrays, which is what John used for the example above. I get that a multi-dimensional array (sElementstoParse)was used in order to store each search string type. Makes sense to me, in that the array can be searched easier as it is better organized. John, what is the purpose of making the array a size of [16][30], as opposed to [8][30], which would fit the 8 elements? Was that just a quickly-sized array so that you knew there was going to be enough space, or is there something else I'm missing with that? If so, does the same hold true for the sWeatherElements array?
Gotta run out real quick so I'll come back to this tomorrow, but the array sElementsToParse is actually a 2-dimensional character array with 16 elements. Initially I was keeping it to a 2-dimensional array to avoid the waste of a much larger ragged array (google "ragged array") and then just keeping track of the elements as being even or odd with this line:
No special reason behind doing it the first way except it was the way my mind processed it when I first typed that line of code. I don't want anyone starting a parameter with me about the way I coded that line .
Yeah, after I re-read the code, I saw the 16 items. I'm just not used to (at least yet) writing code that way, but it definitely makes sense for readability once you know what to look for. I have not tried to compress my code at all yet as I want to see all the inner workings first:
Specifically with this function, I had to do a +26(after counting out the characters in the source) to get the start character to the beginning of the actual current conditions description. Is this ok to do, or should I be implementing another variable to do this for me? I feel like there should be a better way.
Comments
I may be missing some blatently obvious sarcasm, but what would you have to re-write? It's just semantics.
Back to multi-dimensional arrays:
I understand the concept of 2-dimensional and 3-dimensional arrays, which is what John used for the example above. I get that a multi-dimensional array (sElementstoParse)was used in order to store each search string type. Makes sense to me, in that the array can be searched easier as it is better organized. John, what is the purpose of making the array a size of [16][30], as opposed to [8][30], which would fit the 8 elements? Was that just a quickly-sized array so that you knew there was going to be enough space, or is there something else I'm missing with that? If so, does the same hold true for the sWeatherElements array?
Gotta run out real quick so I'll come back to this tomorrow, but the array sElementsToParse is actually a 2-dimensional character array with 16 elements. Initially I was keeping it to a 2-dimensional array to avoid the waste of a much larger ragged array (google "ragged array") and then just keeping track of the elements as being even or odd with this line:
The array looks like an 8 row array because of the way I typed it. I typed it that way for easy editing and readability.
And also, the line of code above could be reduced to No special reason behind doing it the first way except it was the way my mind processed it when I first typed that line of code. I don't want anyone starting a parameter with me about the way I coded that line
--John
That is some line of code, it goes right off the edge of my screen!
Paul
--John
..
DEFINE_FUNCTION fcnWeatherCurr() { STACK_VAR nCurrStart STACK_VAR nCurrEnd STACK_VAR CHAR cCurrCondition[30] IF (FIND_STRING(dvIPWeatherBuff, 'yweather:condition',1)) { nCurrStart = (FIND_STRING(dvIPWeatherBuff, 'yweather:condition',1)+26) nCurrEnd = (FIND_STRING(dvIPWeatherBuff, '"', nCurrStart)) cCurrCondition = MID_STRING(dvIPWeatherBuff, nCurrStart, (nCurrEnd-nCurrStart)) } SEND_COMMAND dvJVCLT37X898Tp, "'^TXT-25,0,',cCurrCondition"Specifically with this function, I had to do a +26(after counting out the characters in the source) to get the start character to the beginning of the actual current conditions description. Is this ok to do, or should I be implementing another variable to do this for me? I feel like there should be a better way.