I'm doing the basic training. I am using browser Google Chrome 54.0.2840.99 m (64-bit) on Windows 10.
I have a date field (Date of Birth). I can use the date picker to select a date of birth. But I cannot enter the numbers by hand. This is unacceptable because one has to scroll back quite a ways to specify a DOB.
Can anyone reproduce this? You can test it out on my test application if you like (if it is up when you try this)
Just add or edit a person and try to change the date by typing numbers in to the date field on browser Chrome. It works on IE or Edge browser
I was able to change both date of birth and date of death by typing in the values into the date fields on the same version of Chrome that you are using.
The date picker will still show when clicking in the input but you are still able to type a date and when you click back into the input the date picker displays the date that you've typed in.
What happens when you focus the input? Anything you type in doesn't populate the input at all?
Thanks, Justin. When I click on the text box to enter numbers for the date, literally NOTHING happens. That is at home.
Now I'm at work. Using the same version of chrome (except it does not have 64-bit in parentheses after the version.). It works fine at work.
So there must be something funky with my browser at home. I'll investigate this 32-bit vs 64-bit thing with Chrome. I was not aware I was specifically using a 64-bit one at home and a 32-bit one at work. Gee, I miss the good old days when we had mainframes and dumb terminals.
Justin Babel wrote:
Hmm, that's strange. Just as a side note, the version of chrome I was using that worked fine was a 64-bit version.
Good luck trying to figure it out. Let me know if there is anything else I can help with.
I'm back home. And now it works. It was clearly a fluke of my keyboard or machine. Likely nothing to do with Outsystems at all.
Sorry to stir you up.
But thanks for confirming it worked for you. Now I've confirmed it works for me ;)
now I'm puzzled. The behavior is back. What happens is that the date widget pops up and there is no way to edit the content of the date box directly. On the Edge browser, when I hover over the date input box with my mouse, I I see a little gray pencil icon. If I click on the date box, the date widget pops up and a text insertion bar appears inside the text box where I clicked. At this point, I have the choice to type in a number and dashes for the date, or I can select a date from the widget.
So I went into developer mode on Chrome and on the edge and copied the HTML. Here are the two for comparison. The browsers showed some of them in a different order, so I rearranged them as that is irrelevant. I notice something very interesting. On Chrome, the HTML delivered has this attribute
But the Edge does not. Perhaps that would explain why I cannot enter stuff. Do you have any idea why that would appear?
In the edge<input name="RichWidgets_wt10$block$wtMainContent$wtPerson_DateOfBirth" tabindex="9" class="ThemeGrid_Width2 ThemeGrid_MarginGutter Mandatory SmartInput ReadOnly" id="RichWidgets_wt10_block_wtMainContent_wtPerson_DateOfBirth" spellcheck="false" onkeydown="return OsEnterKey('RichWidgets_wt10_block_wtMainContent_wt11', arguments || window.event)" type="text" maxlength="20" placeholder="YYYY-MM-DD" value="2000-01-01" autocorrect="off" origvalue="2000-01-01">In Chrome (rearranged to match the edge)<input name="RichWidgets_wt10$block$wtMainContent$wtPerson_DateOfBirth" tabindex="9" class="ThemeGrid_Width2 ThemeGrid_MarginGutter Mandatory SmartInput ReadOnly" id="RichWidgets_wt10_block_wtMainContent_wtPerson_DateOfBirth" spellcheck="false" onkeydown="return OsEnterKey('RichWidgets_wt10_block_wtMainContent_wt11', arguments || window.event)" type="text" maxlength="20" placeholder="YYYY-MM-DD" value="2000-01-01" autocorrect="off" origvalue="2000-01-01" readonly="readonly">
I checked your application using the same chrome version and I wasn't able to reproduce the same behavior. At a first side I can't tell what might be the problem. I have a workaround that is not perfect but you can give it a try.
A way to this is by using jquery where you could have something like
If you want to avoid using jquery you can also try:
Let me know if you need any more help
But I get an error
Uncaught TypeError: Cannot read property 'removeAttribute' of null(…)
Which tells me my getElementById is not finding the element. But why? I determined the element id by using my browser's developer mode (F12).
Can you give me some guidance?
I shouldn't have assume that you already have the whole context, but it's great what you already achieve in that short time!
The missing piece is that you can use the widget ID in the unescaped expression. If you open the expression editor you will check in the scope that the widget input Id (widget input should have a name!) will appear.
where the DummyInput is the name that I gave to the input widget.
Let me know if you need any more help.
OMG, with all due respect Sara, I see your explanation too complicated.
If things haven't changed that much from Outsystems 9.1 to Outsystems 10, jQuery library is already part of your project, so you need to reference nothing.
Just, go to your page properties, and under "advanced" section, add this piece of code:
Moreover, the name that the platform gives to your HTML objects are horrible. You can avoid that by giving a class to your expression. You can add a class name by going to the properties of the expression used and writing something in the "style" property.
Removing theattribute "readonly" using the technique you suggested, does work technically to remove the attribute, but, it does not work as smoothly as we expect.
It technically removes the attribute briefly, but some dynamic code somewhere puts it back.
When the date widgetis first rendered on my desktop, it shows these attributes (among many) on thedate input control
I even went so far as to add a mouseover event on the date input that issued these commands.
These lines can remove the class and any readonly attribute "temporarily."
That finally let me enter text if I was really careful. To do so, I had to mouseover the date of death, then start typing. If I mouse click down in the date of death, the code adds readonly="readonly" to the input, dynamically.
I assume theOutsystems code is clever enough to detect the device I am on and try to adapt.So I did further research: I tried returning the userAgent.
On my desktop, it shows this
MoziIla/5.O(Windows NT 10.0; wow64) AppleWebKit/537.36 (KHTML, like
On my Surface, its hows this
MozilIa/5.0(Windows NT 10.0, Win64: x64) AppleWebKit/537.36 (KHTML
likeGecko) Chrome/55.O.2883.75 Safari/537.36
So I re-installed Chrome on my desktop, to ensure it uses the 64-bit Chrome and not the 32-bit Chrome.
Now my desktop shows this
In other words, my desktop browser is now identical to my Surface browser. They are both the same version of Chrome. But they are different hardware devices.
Obviously this is a bug in code. It is deliberately forbidding entry with the keyboard and popping up the date picker, which is not a good choice on a desktop if you need to go backwards or forwards many years. But I have only seen this so far on my Surface, on Chrome, in Windows 10. On my desktop, on Chrome, on Windows 10, it works fine.
What I want to knowis whether they have tested this on a Surface on Chrome on Windows 10. If anyone else has that combination and could verify this, it would be helpful.
Obviously if this were ME trying to use the application, I would merely switch browsers. The only reason it concerns me is that the world has many users with a Surface and using Chrome. This is not a rare combination.And I was considering Outsystems for a public facing app that will be exposed to a wide variety of hardware and software, and I want it to work in as many cases as possible. Otherwise it causes support issues, or worse, the customer just gives up.
Further ideas are welcome.
We did a little digging to try and further understand the causes of this. Long story short - it's a bug that affects Surface devices and it's already in the backlog for fixing.