You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There has been a requirement of custom String validation of FIX String fields.
For example - Reject messages with null terminating Strings, Strings with unprintable chars , Strings with extended Ascii characters and etc.
What would be the best approach for this?
Modification of the core quickfix code when decoding the message and trying to catch these values and reject or
Handle this via the application implementation itself.
_Note on handling this via the application implementation itself.
Quickfix seems to be converting the above mentioned values to '^' starting Strings before passing to the application logic for null terminating Strings and Strings with unprintable chars. And also messages with fields with extended Ascii characters does seem to be dropped once the message is sent as well._
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi there,
There has been a requirement of custom String validation of FIX String fields.
For example - Reject messages with null terminating Strings, Strings with unprintable chars , Strings with extended Ascii characters and etc.
What would be the best approach for this?
_Note on handling this via the application implementation itself.
Quickfix seems to be converting the above mentioned values to '^' starting Strings before passing to the application logic for null terminating Strings and Strings with unprintable chars. And also messages with fields with extended Ascii characters does seem to be dropped once the message is sent as well._
Any insight would be highly appreciated!
Beta Was this translation helpful? Give feedback.
All reactions