Home AMX User Forum AMXForums Archive Threads Tips and Tricks

Create_Buffer or Data.text

I have an issue with string parsing during feedback. I was using the old fashioned way of creating a buffer and then having a data event to do the feedback. Now i am told that if i create a buffer, the string will not be send to data.text, so all i need is to pass the data.text to a variable and i dont even need to clear the buffer . Has anyone the difference between create_buffer or data.text. Is there a point to write a GET_BUFFER_CHAR(sBoxBuffer) at the end of your string even in data_event


DEFINE_START

//CREATE_BUFFER dvMatrixAudio,sTangoBoxBuffer
DEFINE_MUTUALLY_EXCLUSIVE

([virtualTPDiwaniyaTangoSwt,351].. [virtualTPDiwaniyaTangoSwt,354])
DEFINE_EVENT

DATA_EVENT[dvMatrixAudio]
{
STRING:
{

STACK_VAR CHAR sTmp[50]
STACK_VAR INTEGER nRoom
STACK_VAR INTEGER nSource
sTangoBoxBuffer=data.text
if(FIND_STRING(sTangoBoxBuffer,"$0A",1))
{
//SEND_STRING 0,"'In tango feedback primary',sTangoBoxBuffer"
IF(sTangoBoxBuffer[1] = 'M')
{

sTmp = left_STRING(sTangoBoxBuffer,FIND_STRING(sTangoBoxBuffer,"$0A",1)-1)
// sTmp now i.e.MSST3,2$0AMSC12,0$0A]
// SEND_STRING 0,"'In tango feedback',sTmp"
//GET_BUFFER_CHAR(sTmp)
//SEND_STRING 0,"'In tango feedback get bugger :',sTmp"

SEND_STRING 0,"'In tango feedback string ',sTmp"
// sTmp now i.e. "'D0001=23.5',$0D"
if(FIND_STRING(sTmp,"'MSC'",1))

{ SEND_STRING 0,"'MSC:=',sTmp"
nRoom = atoi(mid_STRING(sTmp,4,FIND_STRING(sTmp,"','",1)-4))
nSource = atoi(right_STRING(sTmp,FIND_STRING(sTmp,"','",1)-3))
SEND_STRING 0,"'msc nRoom=',itoa(nRoom)"
SEND_STRING 0,"'msc nRoom=',itoa(nSource)"
switch (nSource)
{

case 1:
{
[dvTPAmbienceRmsArray,12]=1

[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource1buttons[nRoom]]=1//internal am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource2buttons[nRoom]]=0//am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource3buttons[nRoom]]=0//faisal
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource4buttons[nRoom]]=0//home
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource5buttons[nRoom]]=0//kids
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource6buttons[nRoom]]=0//reem
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource7buttons[nRoom]]=0//kids 1
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource8buttons[nRoom]]=0//kids 2
send_command virtualTPDiwaniyaTangoSwt,"'^TXT-',ITOA(nRoom),',0,Radio1'" //Set audio source




}
case 2:
{

[dvTPAmbienceRmsArray,12]=1

[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource1buttons[nRoom]]=0//internal am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource2buttons[nRoom]]=1//am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource3buttons[nRoom]]=0//faisal
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource4buttons[nRoom]]=0//home
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource5buttons[nRoom]]=0//kids
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource6buttons[nRoom]]=0//reem
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource7buttons[nRoom]]=0//kids 1
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource8buttons[nRoom]]=0//kids 2
send_command virtualTPDiwaniyaTangoSwt,"'^TXT-',ITOA(nRoom),',0,Radio2'" //Set audio source


}
case 3:
{

[dvTPAmbienceRmsArray,12]=1

[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource1buttons[nRoom]]=0//internal am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource2buttons[nRoom]]=0//am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource3buttons[nRoom]]=1//faisal
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource4buttons[nRoom]]=0//home
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource5buttons[nRoom]]=0//kids
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource6buttons[nRoom]]=0//reem
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource7buttons[nRoom]]=0//kids 1
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource8buttons[nRoom]]=0//kids 2
send_command virtualTPDiwaniyaTangoSwt,"'^TXT-',ITOA(nRoom),',0,iPod'" //Set audio source


}
case 4:
{

[dvTPAmbienceRmsArray,12]=1

[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource1buttons[nRoom]]=0//internal am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource2buttons[nRoom]]=0//am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource3buttons[nRoom]]=0//faisal
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource4buttons[nRoom]]=1//home
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource5buttons[nRoom]]=0//kids
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource6buttons[nRoom]]=0//reem
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource7buttons[nRoom]]=0//kids 1
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource8buttons[nRoom]]=0//kids 2
send_command virtualTPDiwaniyaTangoSwt,"'^TXT-',ITOA(nRoom),',0,iPod'" //Set audio source


}
case 5:
{
[dvTPAmbienceRmsArray,12]=1

[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource1buttons[nRoom]]=0//internal am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource2buttons[nRoom]]=0//am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource3buttons[nRoom]]=0//faisal
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource4buttons[nRoom]]=0//home
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource5buttons[nRoom]]=1//kids
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource6buttons[nRoom]]=0//reem
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource7buttons[nRoom]]=0//kids 1
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource8buttons[nRoom]]=0//kids 2
send_command virtualTPDiwaniyaTangoSwt,"'^TXT-',ITOA(nRoom),',0,iPod'" //Set audio source



}
case 6:
{

[dvTPAmbienceRmsArray,12]=1

[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource1buttons[nRoom]]=0//internal am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource2buttons[nRoom]]=0//am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource3buttons[nRoom]]=0//faisal
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource4buttons[nRoom]]=0//home
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource5buttons[nRoom]]=0//kids
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource6buttons[nRoom]]=1//reem
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource7buttons[nRoom]]=0//kids 1
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource8buttons[nRoom]]=0//kids 2
send_command virtualTPDiwaniyaTangoSwt,"'^TXT-',ITOA(nRoom),',0,iPod'" //Set audio source


}
case 7:
{
[dvTPAmbienceRmsArray,12]=1

[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource1buttons[nRoom]]=0//internal am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource2buttons[nRoom]]=0//am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource3buttons[nRoom]]=0//faisal
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource4buttons[nRoom]]=0//home
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource5buttons[nRoom]]=0//kids
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource6buttons[nRoom]]=0//reem
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource7buttons[nRoom]]=1//kids 1
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource8buttons[nRoom]]=0//kids 2
send_command virtualTPDiwaniyaTangoSwt,"'^TXT-',ITOA(nRoom),',0,iPod'" //Set audio source


}
case 8:
{

[dvTPAmbienceRmsArray,12]=1

[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource1buttons[nRoom]]=0//internal am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource2buttons[nRoom]]=0//am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource3buttons[nRoom]]=0//faisal
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource4buttons[nRoom]]=0//home
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource5buttons[nRoom]]=0//kids
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource6buttons[nRoom]]=0//reem
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource7buttons[nRoom]]=0//kids 1
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource8buttons[nRoom]]=1//kids 2
send_command virtualTPDiwaniyaTangoSwt,"'^TXT-',ITOA(nRoom),',0,iPod'" //Set audio source


}
default:
{
local_var integer nloop
local_var integer nRmloop

for(nloop=nRmCount ; nloop>0 ; nloop--)
{
if(nRoom ==nloop)
{
nRmloop++
}
if ( nRmloop==32)
{
[dvTPAmbienceRmsArray,12]=0
}
}

[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource1buttons[nRoom]]=0//internal am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource2buttons[nRoom]]=0//am fm
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource3buttons[nRoom]]=0//faisal
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource4buttons[nRoom]]=0//home
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource5buttons[nRoom]]=0//kids
[virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource6buttons[nRoom]]=0//reem
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource7buttons[nRoom]]=0//kids 1
// [virtualTPDiwaniyaTangoSwt,nRoomAudioStatusSource8buttons[nRoom]]=0//kids 2
send_command virtualTPDiwaniyaTangoSwt,"'^TXT-',ITOA(nRoom),',0,Off'" //Set audio source
}

}



}

}

}
}
}

Comments

  • viningvining Posts: 4,368
    Do a forum search on this subject and you should find a ton of info.

    Either method is fine but if you do create a buffer data.text should still work fine.

    If the device you are receiving data from send a complete string each and every time then data.text by itself is fine. If not you can simply append data.text to a local or global variable. Create buffer does this for you and you either need to clear it or take the pac man approach and remove or get buffer string when a complete string is finally recieved. If you're the copying type right,left, mid string then clearing the buffer is essential. I ike the pac man approach in this situation since I usually will use a "while" find complete string type of conditional.

    In your code below:
    if(FIND_STRING(sTangoBoxBuffer,"$0A",1))
    
    I would change the if to a while. Then remove the code up to and including $0A into a temp stack char str to parse. This way you'll while will keep chugging along until no more complete strings are in the buffer and since you remove them one at a time you don't need to worry creating an inifinite loop.
  • ericmedleyericmedley Posts: 4,177
    /\ /\/\ What vining said /\ /\ /\

    and one thing to add.

    the only major difference is that data.text has a size limit of 2K. But either method will work.
  • so both will work

    Thanks Guys

    I did try putting while instead of an If , but it seems to be in a infinite loop or the feedback may be taking long time

    i am trying to change the status of a room based on if a audio is selected.
    MSC8,1 is the feedback i need to parse but i am not able to get a perfect feedback

    Line 1 (19:31:02):: String From [5001:1:7]-[MVERM804$0A]
    Line 2 (19:31:09):: String From [5001:1:7]-[MSC8,1$0A]
    Line 3 (19:31:20):: String From [5001:1:7]-[MVERM804$0A]
    Line 4 (19:31:32):: String From [5001:1:7]-[MVERM804$0A]
    Line 5 (19:31:37):: String From [5001:1:7]-[MVL8,60$0A]
    Line 6 (19:31:37):: String From [5001:1:7]-[MVL8,39$0A]
    Line 7 (19:31:37):: String From [5001:1:7]-[MML8,32$0A]
    Line 8 (19:31:37):: String From [5001:1:7]-[MVL8,30$0A]
    Line 9 (19:31:38):: String From [5001:1:7]-[MVL8,35$0A]
    Line 10 (19:31:38):: String From [5001:1:7]-[MVL8,35$0A]
    Line 11 (19:31:38):: String From [5001:1:7]-[MVL8,34$0A]
    Line 12 (19:31:38):: String From [5001:1:7]-[MVL8,35$0A]
    Line 13 (19:31:38):: String From [5001:1:7]-[MVL8,34$0A]
    Line 14 (19:31:38):: String From [5001:1:7]-[MVL8,35$0A]
    Line 15 (19:31:38):: String From [5001:1:7]-[MVL8,36$0A]
    Line 16 (19:31:38):: String From [5001:1:7]-[MVL8,38$0A]
    Line 17 (19:31:42):: String From [5001:1:7]-[MSC23,1$0A]
    Line 18 (19:31:48):: String From [5001:1:7]-[MSC23,0$0A]
    Line 19 (19:31:50):: String From [5001:1:7]-[MVERM804$0A]
  • viningvining Posts: 4,368
    Take a look at the example.............
    DATA_EVENT[dvMatrixAudio]
         {
         STRING:
    	  {
    	  STACK_VAR CHAR sTmp[50]
    	  STACK_VAR INTEGER nRoom ;
    	  STACK_VAR INTEGER nSource ;
    	  LOCAL_VAR CHAR cMatrix_RX[1024] ;//COULD BE GLOBAL BUT THAT'S NOT NEEDED
    	  
    	  cMatrix_RX = "cMatrix_RX,DATA.TEXT" ;
    	  (*CREATED A LOCAL VAR TO APPEND WHAT COMES IN ON DATA.TEXT.......*)
    	  (*NOW IF A COMPLETE STRING ISN'T RECEIVED THE LOCAL VAR WILL.....*)
    	  (*HOLD THE RX DATA UNTIL THE REST OF THE STRING ARRIVES..........*)
    	  (*THE ONLY THING THAT REALLY DOESN'T NEED A LOCAL OR GLOBAL VAR..*)
    	  (*FOR THIS PURPOSE ARE STRINGS FROM THE MASTER ITSELF, EVERYTHING*)
    	  (*ELSE SHOULD BE APPENDED TO A VAR. OTHERWISE CREATE BUFFER AND .*)
    	  (*THEN THE MASTER WILL DO THIS FOR YOU...........................*)
    	  WHILE(FIND_STRING(cMatrix_RX ,"$0A",1))
    	       {
    	       STACK_VAR CHAR cMatrix_Tmp_RX[256] ;
    	       
    	       cMatrix_Tmp_RX = REMOVE_STRING(cMatrix_RX ,"$0A",1) ;
    	       (*IF YOU DON'T REMOVE THE STRING YOU SEARCHED FOR IN THE "WHILE"...*)
    	       (*THE WHILE WILL CONTINUE TO BE TRUE AND CONTINUE TO LOOP..........*)
    	       (*IT MUST BE REMOVED!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*)
    	       (*IT DOESN'T MATTER HOW LONG THE DEVICE TAKES TO COMPLETE A STRING.*)
    	       (*WHEN DATA COMES IN IT CHECKS FOR "$0A" IF THERE'S ONE IT TAKES...*)
    	       (*IT AND LOOKS FOR ANOTHER AND WHEN IT CAN'T FIND ANY MORE IT EXITS*)
    	       (*IF THERE WASN'T AN "$0A" IN THE STRING IT EXITS IMMEDIATELY SO...*)
    	       (*IT DOESN'T MATTER HOW SLOW A DEVICE MAY BE, THE MASTER SIMPLY....*)
    	       (*MOVES ON UNTIL ANOTHER CHUNK OF DATA IS RECEIVED.................*)
    	       SELECT
    		    {//NOTE I DON'T KNOW WHAT THE "8" INDICATES
    		     //SO YOU MAY NEED TO ADD IT TO YOUR FIND_STRING OR PARSE IT
    		    ACTIVE(find_string(cMatrix_Tmp_RX,'MVERM',1)):
    			 {
    			 //PARSE 'MVERM'
    			 }
    		    ACTIVE(find_string(cMatrix_Tmp_RX,'MML',1)):
    			 {
    			 //PARSE 'MML'
    			 }
    		    ACTIVE(find_string(cMatrix_Tmp_RX,'MSC',1)):
    			 {
    			 //PARSE 'MSC'
    			 }
    		    (*     ADD MORE IF OTHER POSSIBILITIES EXIST
    		    ACTIVE(find_string(cMatrix_Tmp_RX,''NEXT STRING'',1)):
    			 {
    			 //PARSE 'NEXT STRING'
    			 }
    		    *)
    		    ACTIVE(1)://
    			 {
    			 //NO NEED TO DUMP STRING YOU DON'T CARE ABOUT SINCE THE STRING 
    			 //IS HELD IN A STACK VAR AND THE STACK SIMPLY VANISH WHEN THE CODE
    			 //BLOCK IS EXITED.........................
    			 }
    		    }
    	       }
    	  }
         }
    
  • The site here consists of 6 controllers with 25 panels connected to different controllers. Tango is connected to one controller with a duet module running it, now i ve realized that if a duet moduel is running, then if there is a data event for the actual device, it may not work.

    Also since i am not able to get feedback i thought of writing this code, now i am thinking that to write some thing in mainline so that i keep updating all the panels.
  • viningvining Posts: 4,368
    Well if it's a duet module you typically will not get anything via DATA.TEXT or a created buffer. Most duet modules do provide the ability to passback the data coming form the device via a "PASBACK-1" command. Well I think that's the command although I don't use AMX modules too often and rarely if ever use a duet module. So if you want to handle RX data yourself put the "PASSBACK" command in the virtuals online event and you should be golden (providing the module supports it).
  • Guess that explains everything. I was trying to figure feedback was not coming. Since duet module resides in the controller and the rest of the controller references this module, there is a delay in the feedbacks and sometimes the commands dont even go. I am thinking whether i should just write everything directly rather than use a module,
  • Whenever this has come up in discussions with AMX Engineering, I have been told that CREATE_BUFFER will receive the incoming strings faster than a DATA_EVENT will. So, if I am receiving a large amount of data, generally, I will always capture the data via a CREATE_BUFFER, but process the buffer in a DATA_EVENT. In that way, the DATA_EVENT provides the interrupt when there is something to process with the received strings sitting in the buffer variable. Depending on the amount of data that you are receiving, you generally still have to validate that you have a complete response and that you haven't grabbed only a portion of the incoming strings.

    However, if I am just receiving string responses from a TP for instance, such as page tracking, I will simply handle this via the DATA_EVENT directly without a CREATE_BUFFER.

    Hope this helps.
  • a_riot42a_riot42 Posts: 1,624
    ipssheldon wrote: »
    Whenever this has come up in discussions with AMX Engineering, I have been told that CREATE_BUFFER will receive the incoming strings faster than a DATA_EVENT will. So, if I am receiving a large amount of data, generally, I will always capture the data via a CREATE_BUFFER, but process the buffer in a DATA_EVENT. In that way, the DATA_EVENT provides the interrupt when there is something to process with the received strings sitting in the buffer variable. Depending on the amount of data that you are receiving, you generally still have to validate that you have a complete response and that you haven't grabbed only a portion of the incoming strings.

    However, if I am just receiving string responses from a TP for instance, such as page tracking, I will simply handle this via the DATA_EVENT directly without a CREATE_BUFFER.

    Hope this helps.

    I have heard this as well, but doubt that it is actually true in all cases. In my Sonos module I tried both data.text and create_buffer and there are some distinct advantages to using data.text so I am using it rather than create_buffer. Even with incoming files that are over 100KB it still works fine and is just as fast as create_buffer and has the added advantage that I can peek at the incoming data while its coming in rather than after it has all been received into the create_buffer. I suppose it wouldn't be difficult to devise a test to see which processes data faster, data.text or create_buffer.
    Paul
  • dchristodchristo Posts: 177
    a_riot42 wrote: »
    and has the added advantage that I can peek at the incoming data while its coming in rather than after it has all been received into the create_buffer.

    Could you expand on this?

    --D
  • a_riot42a_riot42 Posts: 1,624
    dchristo wrote: »
    Could you expand on this?

    When parsing data from an IP stream, the string event gets run every 1500 bytes so I can look at the data as it trickles in. In the case of HTTP I can parse the packet header without having to buffer the body which is useful in the case of Sonos as the body can be arbitrarily large.

    Using create_buffer and processing the data in the ports offline event as is recommended by AMX means that you have to wait until the controller decides to fill the buffer before you can deal with the data. This isn't always optimal so I prefer to use data.text and look after the buffering myself. I would guess that data.text is no slower than create_buffer and may even be faster in some instances depending on the data being parsed and the size of the buffer.
    Paul
  • dchristodchristo Posts: 177
    a_riot42 wrote: »
    Using create_buffer and processing the data in the ports offline event as is recommended by AMX means that you have to wait until the controller decides to fill the buffer before you can deal with the data. This isn't always optimal so I prefer to use data.text and look after the buffering myself.

    There's certainly nothing wrong with your approach, but I think you're mischaractarizing (is that a word?) the Create_Buffer. Using Create_Buffer does not force you to wait until the processors fills it... it's filled at the same time Data.Text is. The buffer created with Create_Buffer is available in the String event just like Data.Text. It has been reported (although I've never seen any tests to prove it), that using Create_Buffer is more efficient than manually concatenating a buffer using Data.Text (possibly due to more efficient low-level routines in the OS rather than in the interpreter). There's no reason to wait until the Offline event before using the Create_Buffer method.

    There is certainly no reason you couldn't use both methods... they're both useful tools in the right circumstance.
    DEFINE_VARIABLE
    Char strBuffer[512]
    
    DEFINE_START
    Create_Buffer dvSomeDevice, strBuffer
    
    DEFINE_EVENT
    Data_Event[dvSomeDevice]
    {
       String:
       {
          // the first time the event fires, strBuffer == Data.Text
       }
    }
    
  • viningvining Posts: 4,368
    a-riot42 wrote:
    processing the data in the ports offline event as is recommended by AMX
    I don't know why they would recommend that unless their thinking is that if you're doing an HTTP type connection request and don't really know what the contents of the RX data will be, the offline event handler is the best way to determine you've reached the end of the data and for parsing things like large web pages that's fine cuz you rarely need to process that data quickly. Otherwise, if you know what you're looking for I would always think triggering the parsing routine in the string event handler regardless of data.text appended or not or using a created buffer is the preferred way to go.

    So if the string event triggers on every MTU chunk (1500 bytes max for TCP) you could check the created buffer, a local/global appended var of data.text or straight data.text in the same manner. As far as what's more effiecient, I don't really know and probably could care less. Of course if I knew for sure I might opt for that method just because.
  • a_riot42a_riot42 Posts: 1,624
    dchristo wrote: »
    There's no reason to wait until the Offline event before using the Create_Buffer method.

    That's true. But if you are going to process the stream in the string handler anyway, I don't see the point of using create_buffer. Then you are using two buffers, data.text and the buffer and the buffer gets filled first before the string handler is run, so I presume that would add some delay to the processing. If there is an advantage to using create_buffer I would happily use it, I just haven't found any advantage, and have seen some disadvantages. I always thought it was a legacy function held over from before events were added to Netlinx.
    Paul
Sign In or Register to comment.