Issues
When using a formlist it's not possible to have form buttons such as edit and save. The alternative is to make the form editable by default and to enable form auto-save. This gets us a workable solution.
This brings up another issue though. Radio buttons in the form are greyed out and only become editable when clicking another field of the same table row first. The reason for radio buttons is to prevent drop-downs to minimize mouse clicks.
Request
I would like to see formlists tweaked by the developers so that they behave somewhat more like a normal form, including buttons that can be relevant for formlists (such as edit, save and cancel). And ideally radio buttons in formlists are clickable immediately.
Note
Maybe this should have been an idea rather than a question. 😉
Page 1 / 1
Hey Roland,
For the greyed out radio button issue, I encountered it too but with Checkboxes. I already made an issue in TCP and it should be fixed by the next release.
For the buttons, sadly currently no solution. Making an idea of this will let our Product Innovation team know we want this feature.
Kind regards,
Mark Jongeling
For the greyed out radio button issue, I encountered it too but with Checkboxes. I already made an issue in TCP and it should be fixed by the next release.
For the buttons, sadly currently no solution. Making an idea of this will let our Product Innovation team know we want this feature.
Kind regards,
Mark Jongeling
The upcoming GUI release of today indeed contains fixes for unnecessary grayed out controls in the Formlist.
The Formlist comes up been default editable in all cases. As a developer you could only influence the AutoSave option on a Formlist. You could choose to turn it of to prevent users from doing unwanted edits on the displayed data values.
A workaround to show the form buttons on the screen for now could be to place a dummy form beneath the Formlist?
Regards, Erik
The Formlist comes up been default editable in all cases. As a developer you could only influence the AutoSave option on a Formlist. You could choose to turn it of to prevent users from doing unwanted edits on the displayed data values.
A workaround to show the form buttons on the screen for now could be to place a dummy form beneath the Formlist?
Regards, Erik
It's funny how I keep requesting changes that are already in the pipeline for release. 
But that's great news of course. That simply means I'll be upgrading from 2019.1 very soon.
But that's great news of course. That simply means I'll be upgrading from 2019.1 very soon.
To be clear, the formlist is a feature of the GUI. So I mend the Windows GUI release of today solving those issues.
Unfortunately after upgrading to the latest release (2019.2) the radio button issue still occurs. Here are pictures to illustrate what happens:
The radio buttons are greyed out. The check boxes work but they already did before the upgrade.
Only after clicking inside a row the radio button becomes accessible. It's clearly visible how only the radio buttons in that row turn from grey to black.
The expected result was that the radio buttons would all be black and accessible immediately and all at once.
The radio buttons are greyed out. The check boxes work but they already did before the upgrade.
Only after clicking inside a row the radio button becomes accessible. It's clearly visible how only the radio buttons in that row turn from grey to black.
The expected result was that the radio buttons would all be black and accessible immediately and all at once.
Could you please report this issue in TCP, if not already?
Thanks you for getting back about this subject!
Kind regards,
Erik
Thanks you for getting back about this subject!
Kind regards,
Erik
Will do!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.