Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X
Dear community,
I am using textfield widgets to support building a SQL statement, including the where clause. Unfortunately textfields show a weird behavior when entering "<>", the characters seem to be interpreted and replaced by other characters. The replacing characters consume more space, the rest of the text is visibly moving to the right.
This reminds me of MS Office where for example a dash automatically starts a bullet list. This could be nice in some cases but here I certainly do not want any kind of this interpretational behavior. Not sure whether this is a bug or a feature going the wrong direction.
I am working on Release 9.3.9.
Screenshots "<" works fine:
Screenshot "<>" does not work:
Many thanks for any pointer
Benny
Solved! Go to Solution.
I tested in my 9.4.2 and there is a replacement happening indeed, only when the "<>" series is being input.
The resulting characters are the "full-width" versions of those being input.
I suggest opening a support case to diagnose if this is a bug. I suspect this being a security feature to protect from possible SQL injection attacks, but let's see.
You can use an expression to catch this situation and replace the <>with the <>
I tested in my 9.4.2 and there is a replacement happening indeed, only when the "<>" series is being input.
The resulting characters are the "full-width" versions of those being input.
I suggest opening a support case to diagnose if this is a bug. I suspect this being a security feature to protect from possible SQL injection attacks, but let's see.
You can use an expression to catch this situation and replace the <>with the <>
Vladimir, you continue becoming a personal hero of mine. Many thanks for investigation and your feedback.
I haven't thought about the workaround, that will very likely work for my use case.
I wouldn't understand this as a security feature. You can still build any queries, you would need to replace many more characters, such as single < or >. However, if a support case is the right way to go, I will take that route.
Thank you again.