cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Learn all about PTC Community Badges. Engage with PTC and see how many you can earn! X

Textfield widget does not accept "<>"

BennyB
16-Pearl

Textfield widget does not accept "<>"

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:

bbeuckSIG_0-1699623713473.png

bbeuckSIG_1-1699623741042.png

 

Screenshot "<>" does not work:

bbeuckSIG_2-1699623828366.png

bbeuckSIG_3-1699623847306.png

 

Many thanks for any pointer

Benny

 

 

 

ACCEPTED SOLUTION

Accepted Solutions
VladimirRosu
19-Tanzanite
(To:BennyB)

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 <>

 

View solution in original post

2 REPLIES 2
VladimirRosu
19-Tanzanite
(To:BennyB)

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.

Announcements


Top Tags