Postmessage limitation

[Ron]

256 integers ? wow thats a lot!

The buffer holds upto 250 characters including the terminating

[Ron]

Maybe you could put in some smart compression
technique. What does the data represent ?

-Ron

[MatB]

Hi, i've got a question about the PostMessage in Hardware plugins.
The driver i'm writing uses quite long signal streams, i.e. 256 integers. As i may see, the actual size of the buffer is 16 chars, and they must contain a string, with no special chars, like zeroes, 0x13... So, i've got an unplanned problem. Is that right?

What's about the learn_device function? May i keep the collection of long streams on the dll side, and send a representative string to the app?

[MatB]

Well, it works quite good.
When i learn, i save the my long data in a array, and send to girder a string containing the reference to the array.
The only problem is that when girder erases a command, my array doesn't, and grows...

[MatB]

The data represents the data streams (>=1) timings received from the serial port corresponding to a single remote button.
It's so cause i experienced recepcion of commands in "multiple flavours". Maybe it's my hardware, but not the remote, since it happens with all the RC5 remotes i have.
I could cheaply transform the _int32 to _int16, halving the data size.
Anyway, it's not a prioritary problem, cause it works the way it is. Maybe i'll get back on this later.