Home AMX User Forum AMXForums Archive Threads AMX Applications and Solutions

how do you use IP_CLIENT_OPEN to get info from a website?

124»

Comments

  • PhreaKPhreaK Posts: 966
    Hedberg wrote: »
    Yeah, don't want to get into a parameter with the lingo police.
    That comment just made my morning :)
    Hedberg wrote: »
    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.
  • vegastechvegastech Posts: 369
    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?
  • vegastech wrote: »
    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:
    sWeatherElements[nParseLoop] = fnWeatherAttrParse(sElementsToParse[(((nParseLoop-1)*2)+1)],sElementsToParse[(((nParseLoop-1)*2)+2)],cBuffer)
    

    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
    sWeatherElements[nParseLoop] = fnWeatherAttrParse(sElementsToParse[((nParseLoop*2)-1)],sElementsToParse[(nParseLoop*2)],cBuffer)
    
    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
  • a_riot42a_riot42 Posts: 1,624
    sWeatherElements[nParseLoop] = fnWeatherAttrParse(sElementsToParse[(((nParseLoop-1)*2)+1)],sElementsToParse[(((nParseLoop-1)*2)+2)],cBuffer)
    

    That is some line of code, it goes right off the edge of my screen!
    Paul
  • a_riot42 wrote: »
    That is some line of code, it goes right off the edge of my screen!
    Paul

    :)


    --John

    ..
  • vegastechvegastech Posts: 369
    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:
    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.
Sign In or Register to comment.