SEND_STRING 0 acts like a NULL terminated C string

Joe Hebert

The Notifications and Diagnostics windows do a good job of substituting each non printable byte with a $ sign followed by its 2 digit hex value - except when a NULL is reached in a SEND_STRING 0. The SEND_STRING 0 gets terminated as soon as it reaches a NULL as if it were a C string.

For example:

SEND_STRING 0, "'12',1,2,255,$48,'ello',0,' there'"

Prints this in the Diag window:

Line 1 :: 12$01$02$FFHello - 05:16:33

When it should have printed this:

12$01$02$FFHello$00 there

Can this get fixed in a future rev of Netlinx Studio?

Thanks.

DHawthorne

I think this is because that is the way C++ handles strings ... a null terminates a string always. I believe this to be one of those things you simply have to avoid doing; it's intrinsic to the programming language in which Studio was written. Last I heard, Studio is just a branded adaptation of Microsoft Visual Studio, so the editor functions and workspace managers aren't even AMX code, just the compilers.

Chip Moody

Don't think this just applies to SEND_STRING 0's, either.

I.E., if you have a device that you're sending strings to, and some of those strings contain $00, you're not going to see anything following the preceeding byte in either NetLinx Diagnostics while monitoring strings going out to devices, OR if you do a S_S 0 with that same string for debugging purposes.

So, unfortunately it's not something that CAN be avoided - Studio/Diagnostics should deal with it properly by some means, just like it deals with other non-printable codes. Hey - if those strings can be sent out to our devices without getting prematurely terminated by a $00, they should be able to get to a freakin' debug window just as easilly.

- Chip

Joe Hebert

If I monitor strings going to/from a device with the Netlinx Notifications window then the strings don?t get lopped off with after the first NULL and everything prints out fine.

For example:

DEFINE_DEVICE

dv232	= 5001:1:0
dvTP	= 10001:1:0

DEFINE_EVENT

BUTTON_EVENT[dvTP,1] {

   PUSH: {
      SEND_STRING dv232, "'12',1,2,255,$48,'ello',0,' there'"
      SEND_STRING 0, "'12',1,2,255,$48,'ello',0,' there'"
   }
}

The SEND_STRING dv232 in the Notifications window prints out correctly:
Line 1 :: String To [5001:1:10]-[12$01$02$FFHello$00 there] - 14:01:40

The SEND_STRING 0 in the Diagnostics window does not:
Line 1 :: 12$01$02$FFHello - 14:01:40

Chip wrote:

Hey - if those strings can be sent out to our devices without getting prematurely terminated by a $00, they should be able to get to a freakin' debug window just as easilly.

I agree 100%. I don?t care what language or platform Netlinx Studio is written in. We shouldn?t have to avoid sending NULLs with SEND_STRING 0. Neltinx Studio should be fixed.

DHawthorne

It's not just nulls either, really. It's any high or low order ASCII. This is a terminal window, after all. I agree entirely that any editor window or notification window should handle non-printable characters (including null) more gracefully, but the terminal window is a little different, because there are lots of ways to access it that have nothing to do with the programming enviroment. For that reason, I filter every character I pass to it in code, and replace non-printable characters with the decimal value. You can get wierder effects than a prematurely terminated string passing along some of those characters to a Telnet session, for example. An argument could be made for it being done in the master though.

Chip Moody

I swear I had this as a problem on several occasions. But y'know what? I'm not going to fire up Studio just to screw with this - at least not right now. I'll try to recreate what I saw next time I think of it and have a few minutes.

- Chip

Joe Hebert wrote:

If I monitor strings going to/from a device with the Netlinx Notifications window then the strings don?t get lopped off with after the first NULL and everything prints out fine.