text_field Issue in HH:mm for NG Client

Classic Servoy
1

We have text_field and showing data into HH:mm
In smart client it seems working proper and as expected but when we run the same in NG Client then below error is coming

ERROR org.sablo.websocket.utils.JSONUtils - Error while converting value: 12:10 of key: null to type: org.sablo.specification.property.types.LongPropertyType@321394d6 current json: null

Hence can you please guide us what is wrong in above ASAP?

2

Can you give more info? Like:

  • what is the type of the dataprovider for that field? (numeric column/var or Date or …)
  • do you have a full stack trace for that error in servoy_log.txt file?
  • does this happen when editing the value on client or when showing the form?
  • the actual value of in the dataprovider at that time.
3

Sure.

  1. type of the dataprovider is TEXT but in database its INT. So assume that if HH:mm value is say 01:00 then in database value would be 60, if 02:00 then 120 in this way.

ERROR com.servoy.j2db.util.Debug - A dataprovider that is not able to send itself to client… (PropertyDescription[name: Dataprovider (int), type: org.sablo.specification.property.types.LongPropertyType@321394d6, config: null, default value: null], 12:10)

  1. When form is open at that time value is not showing into text_field
4

I think I need a small sample with only one form and one text field to see this.

I did try it out with a new table with one int column, column converter (table editor column settings) int (minutes) → String (HH:mm) and put a text field on that column with format HH:mm. Converters worked fine.
But it doesn’t show anything useful in Smart Client either. It shows “:mm” when in DB I have 601 for example.
And it is to be expected because that format is not a date format but a String format where HH means uppercase hex char and :mm means nothing…

So you must be doing it in a different way.

BTW, at point 2 above I was aiming for a full stack trace - if available. Also I see from that message that the dataprovider seems to be int not string.

5

Hi Andrei

Thanks for you feedback.

Let me give you the full stack trace and the approach we are using.

KIndly find the attached files for the same.

  1. servoy_log.txt → full stack
  2. DB Snap → database the field and logic

Let us know if you need any further details.

db snap.jpg
db snap.jpg1224×346 64.5 KB

servoy_log.txt (121 KB)

6

Ok, the stack trace hinted that the DP thinks it’s a number when it actually is a String.
I was able to reproduce the problem in my sample by removing the format from the text field.

Support case SVY-12014 is created.
You can follow that case to see when it is fixed (will probably be fixed in 8.2.3).

As a workaround until this bug is fixed you can set a format (like “##:##” - or anyway, a format that does what you need) on the field. That helps the text field find the right type for the DP.