Home AMX User Forum NetLinx Studio

get_buffer_char() not working?

I'm actually in Prog-II training class in Chicago today. Todd & crew send their love ;-)

While working on a string parsing exercise, the GET_BUFFER_CHAR() command was not returning any value. It would strip the first character off the CHAR array, but would not return a value.
define_call 'parse_string' (char this_string[128]) { 
   stack_var char first_char[2]
   send_string debug,"'Got String: ',this_string"
   first_char = get_buffer_char(this_string) 
   send_string debug,"'First Char: ',first_char"
   send_string debug,"'Remaining String: ',this_string" 
}
This code returns the following information on debug:

Got String: gobbledygook
First Char:
Remaining String: obbledygook

Of course remove_string works as advertised, and using left_string with another character stripping command works too. Has anyone else run into this?

Comments

  • ericmedleyericmedley Posts: 4,177
    I'm actually in Prog-II training class in Chicago today. Todd & crew send their love ;-)

    While working on a string parsing exercise, the GET_BUFFER_CHAR() command was not returning any value. It would strip the first character off the CHAR array, but would not return a value.
    define_call 'parse_string' (char this_string[128]) { 
       stack_var char first_char[2]
       send_string debug,"'Got String: ',this_string"
       first_char = get_buffer_char(this_string) 
       send_string debug,"'First Char: ',first_char"
       send_string debug,"'Remaining String: ',this_string" 
    }
    
    This code returns the following information on debug:

    Got String: gobbledygook
    First Char:
    Remaining String: obbledygook

    Of course remove_string works as advertised, and using left_string with another character stripping command works too. Has anyone else run into this?

    I have had flaky results with Get_Buffer_Char. It is old-skool stuff left over from Axcess days. I tend not to use it much since there are so many other ways to do basically the same thing. Hence, I've never really investigated what's going on. I'd be curious to find out, however, since it is a handy way to strip of the first char of a string.
  • mpullinmpullin Posts: 949
    Why is first_char declared as an array of 2 chars? If you simply declare it

    stack_var char first_char

    I think you'll be okay. I can't quite explain why it behaves the way it does though.
  • Matt is right, the recipient string has to be declared as a single character string. If it is any longer, the get_buffer_char operation throws a GetString / CopyString error 1 visible if you telnet in and "msg on".

    The help says "Result is a CHAR or WIDECHAR value depending on the variable type of Array" which sort of implies this restriction.

    "Why does the compiler allow it?" you may ask - another subtle compiler bug.

    This looks like *yet another* example of the good old NS2 "Single character strings are sometimes flaky" problem, although back to front.
  • AM93AM93 Posts: 10
    Your problem is that you need to specify which index your are putting the char into. It won't do it automatically for you. Even though you could assume it would be put into index 1...that may not necessarily be the case in a multi-dimensional array obviously...

    So

    First_Char[1] = Get_Buffer_Char(This_String)
  • dchristodchristo Posts: 177
    You may also want to try putting the GET_BUFFER_CHAR inside of double quotes. I frequently use the following without problems:
    Char strTrash[512]
    ...
    
    strTrash = "Get_Buffer_Char(strSomeString)"
    

    --D
  • Experiment shows that dchristo is right - double quotes fix the problem - which is a common solution; it seems necessary to surround the RHS of almost every string assignment with double quotes to insure against the good old "single character string is flaky" issue.

    [Everyone: off you go and do that now!]

    Experiment also shows that AM93 is mistaken. Good idea, but specifying the index on the LHS does not apparently solve the problem and I have not experienced a similar solution elsewhere. I think.
    you need to specify which index you are putting the char into. It won't do it automatically for you

    Unfortunately this is simply wrong for a single dimension string.

    May I urge contributors to this forum to experiment before they post?
  • viningvining Posts: 4,368
    Posted a few month ago by AMXJeff:

    Although this was refferring to the use of ATOI and get_buffer_char the same principle applies.
    GET_BUFFER_CHAR returns a CHAR not a CHAR[1]. So the return value does not have length and is not a char array. ATOI needs a CHAR array. By adding the quotes around GET_BUFFER_CHAR you are actually creating a CHAR array via concatenation. Now ATOI is happy.


    // System Function Declerations
    DEFINE_FUNCTION CHAR GET_BUFFER_CHAR(CHAR cMsg[])

    DEFINE_FUNCTION INTEGER ATOI(CHAR cMsg[])
  • AM93 wrote:
    First_Char[1] = Get_Buffer_Char(This_String)

    Sorry it took so long to get back to the forums on this. mpullin and AM93 are both right:

    Defining a char without a length will allow it to receive the output of get_buffer_char. So will specifying which position (as above) the output goes into. It just doesn't work if you give the variable a length when you define it, and then don't specify a position to put the result into.

    Although get_buffer_char() is one of the 'old' commands from the axess days, it still does something no other single string operator does: gets the first character without knowing what it is, and 'rolls' the buffer too. You have to know what character it is to get the same effect from remove_string().

    I'm not sure I would recommend using get_buffer_char() if you don't really need that particular function, but that seems to be mostly the ongoing oddities of dealing with single character storage. As long as you know how to make it work - and AM93's solution above is the more 'recommended' way - you'll be OK.
  • AMXJeffAMXJeff Posts: 450
    Actually, I would say the mpullin is the preferred way, since the function returns a CHAR not a CHAR[1] with length. If you need length, the preferred way would be....

    // If you just need the char (preferred)
    STACK_VAR CHAR TEST;
    
    TEST = GET_BUFFER_CHAR(buffer);
    
    


    // If you need length
    STACK_VAR CHAR TEST[1];
    
    TEST = "GET_BUFFER_CHAR(buffer)";
    
    
    Sorry it took so long to get back to the forums on this. mpullin and AM93 are both right:

    Defining a char without a length will allow it to receive the output of get_buffer_char. So will specifying which position (as above) the output goes into. It just doesn't work if you give the variable a length when you define it, and then don't specify a position to put the result into.

    Although get_buffer_char() is one of the 'old' commands from the axess days, it still does something no other single string operator does: gets the first character without knowing what it is, and 'rolls' the buffer too. You have to know what character it is to get the same effect from remove_string().

    I'm not sure I would recommend using get_buffer_char() if you don't really need that particular function, but that seems to be mostly the ongoing oddities of dealing with single character storage. As long as you know how to make it work - and AM93's solution above is the more 'recommended' way - you'll be OK.
  • I know it is not technically a single string operator, since it is two different commands, but you could do the following:
    cFIRST_CHAR = REMOVE_STRING(strSTUFF,LEFT_STRING(strSTUFF,1),1)
    
    

    I do not have a master to test this on, but I think it would perform the same way as GET_BUFFER_CHAR except it would be more robust.
  • AMXJeffAMXJeff Posts: 450
    Actually if your going to do that...
    STACK_VAR CHAR TEST[1];
    
    TEST = GET_BUFFER_STRING(cBuffer,1);
    
    


    I know it is not technically a single string operator, since it is two
    different commands, but you could do the following:
    cFIRST_CHAR = REMOVE_STRING(strSTUFF,LEFT_STRING(strSTUFF,1),1)
    
    

    I do not have a master to test this on, but I think it would perform the same way as GET_BUFFER_CHAR except it would be more robust.
Sign In or Register to comment.