I am trying to setup 2 time input fields for a mobile access application. Using RPGLE and Rich Display files. I have tried several combinations to get the input fields working, but I have yet to hit a combination that works.
Initially I had the data field set to TIME type and on the RDF I had the input type set as "time" so that it would pop up the mobile browser's time interface and that works well. But I would occasionally get "time not valid format" errors when attempting to submit the screen. And under other circumstances it would input fine, but would not display the time if it was already set.
So I decided to try using a decimal field (I have used 6,0 and 4,0) for the field and the input type set to "time". This setup comes the closest to working as I would expect it to. I am able to input the time and it is not giving me any errors. But if a time exists in the field and it is under 10:00 - it does not display the time. If it is over 10:00 it shows it as expected. I am currently using a 4,0 decimal field, input type set to Time. And in the code I am converting the time field to a 4,0 decimal to output to the screen.
This example shows the time fields and just above them is an output field that is the same that is used for the time field.
Any thoughts on why it is doing this or is there a simpler way to input and display time fields?
Time entry
-
- New User
- Posts: 6
- Joined: Tue May 01, 2018 12:57 pm
- First Name: Kevin
- Last Name: Nunn
- Company Name: Eclipse Consulting
- Contact:
-
- New User
- Posts: 6
- Joined: Tue May 01, 2018 12:57 pm
- First Name: Kevin
- Last Name: Nunn
- Company Name: Eclipse Consulting
- Contact:
Re: Time entry
Testing this situation with a "Time" Data type:
If I leave the "input type" as blank, it displays the time correctly
If I set the input type to "Time" to trigger the UI of the mobile browser, it no longer displays the exiting value of the field.
If I leave the "input type" as blank, it displays the time correctly
If I set the input type to "Time" to trigger the UI of the mobile browser, it no longer displays the exiting value of the field.
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: Time entry
Under the covers, a textbox widget inserts an <input> html tag into the web page. When you set the "input type" property in that widget, it outputs the widget with a type attribute, such as <input type="time">. So this is just a very simple wrapper around the HTML capabilities, which are still relatively new (and have been changing over the last few years in browser support.)
You can read about how browsers see or interpret the input type time here:
https://developer.mozilla.org/en-US/doc ... input/time
When you use this functionality, you are expected to provide the data in the exact format that the browser expects. That means you must use the binding/formatting dialog to make it fit that type correctly. Browsers do not have the concept of numeric fields, so they may return values that aren't valid numbers. That being the case, I would never bind a numeric field to a type=time textbox -- unless, of course, you have written a custom formatter that will ensure it is handled properly.
I like using the type=date and type=time in mobile devices because its often much easier to select dates/times this way. I would not recommend using them in desktop applications. Times just aren't that complicated! I would just use a plain textbox... or if you want a little more, use separate fields for hours/month, and put the options into spinner fields or dropdowns.
You can read about how browsers see or interpret the input type time here:
https://developer.mozilla.org/en-US/doc ... input/time
When you use this functionality, you are expected to provide the data in the exact format that the browser expects. That means you must use the binding/formatting dialog to make it fit that type correctly. Browsers do not have the concept of numeric fields, so they may return values that aren't valid numbers. That being the case, I would never bind a numeric field to a type=time textbox -- unless, of course, you have written a custom formatter that will ensure it is handled properly.
I like using the type=date and type=time in mobile devices because its often much easier to select dates/times this way. I would not recommend using them in desktop applications. Times just aren't that complicated! I would just use a plain textbox... or if you want a little more, use separate fields for hours/month, and put the options into spinner fields or dropdowns.
-
- New User
- Posts: 6
- Joined: Tue May 01, 2018 12:57 pm
- First Name: Kevin
- Last Name: Nunn
- Company Name: Eclipse Consulting
- Contact:
Re: Time entry
Thank you for the fast and informative response Scott. That does clear things up and thanks for the suggestion. That is how I was originally was doing it, but then I figured it would be nice to have the time widget handle things, but looks like not. I'll go back to my original idea :)
Kev
Kev
-
- New User
- Posts: 6
- Joined: Tue May 01, 2018 12:57 pm
- First Name: Kevin
- Last Name: Nunn
- Company Name: Eclipse Consulting
- Contact:
Re: Time entry
Although... this project is meant to be mobile, so I will see about implementing that side of it once it reaches that stage.
Kev
Kev
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: Time entry
Well, the widget works fine, as long as you're willing to accept that things have to be sent/returned in the exact format that the browser expects.
Who is online
Users browsing this forum: Bing [Bot], Google [Bot] and 3 guests