It would be real nice if when using radio buttons I could specify how many buttons per line in the AppGini program rather than having to go into each filename_dml.php file and changing it there.
Just a thought....
$combo_shift->RadiosPerLine = 3;
Radio Button Layout
Re: Radio Button Layout
Hi,
yes, sounds good.
Also, I do not see a (big) problem, as, if one decides to use radio buttons, one usually knows how many there are (or at least will there be at maxium).
Olaf
yes, sounds good.
Also, I do not see a (big) problem, as, if one decides to use radio buttons, one usually knows how many there are (or at least will there be at maxium).
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: Radio Button Layout
The idea is good, but there is a problem: Due to necessary compatibility with different screen sizes on different devices (Desktop, Tablet, Smartphone) in landscape or portrait mode, you will have to calculate a "correct" width per radio and adjust the css-width of the controls. But that strongly depends on the display environment AND on the different string-lengths (label-widths) of the options. You cannot ensure a fixed number of radios per line because you do not know the avaialable space at the endpoint and you do not know the widths of all (visible) options beforehand.
I did some experiments the last days and I'm not satisfied with the results, see screenshots on different screen size emulations. Cutting the labels to a maximum width would solve the problem with different widths. But you lose information. So we need a different approach.
I think for avoiding trouble with different screen sizes, a solution should be based on Bootstrap's grid-system. So for example we could be able to configure:
So an approach for handling the requirement given in the beginning could be:
Add a div.row to the div which contains the radios, then for each radio append a div.col-xs-aaa.col-sm-bbb.col-md-ccc.col-lg-ddd with best-possible aaa, bbb, ccc, ddd.
Doing it this way would not allow you to freely define the number of radios per row, but it would allow more than one radio per row AND a well aligned layout, compatible with different device sizes and resolutions.
I did some experiments the last days and I'm not satisfied with the results, see screenshots on different screen size emulations. Cutting the labels to a maximum width would solve the problem with different widths. But you lose information. So we need a different approach.
I think for avoiding trouble with different screen sizes, a solution should be based on Bootstrap's grid-system. So for example we could be able to configure:
- in xs-devices, there shall be 1 radio per row
- in sm: 2 radios
- in md: 3 radios
- and in lg: 4 radios
So an approach for handling the requirement given in the beginning could be:
Add a div.row to the div which contains the radios, then for each radio append a div.col-xs-aaa.col-sm-bbb.col-md-ccc.col-lg-ddd with best-possible aaa, bbb, ccc, ddd.
Doing it this way would not allow you to freely define the number of radios per row, but it would allow more than one radio per row AND a well aligned layout, compatible with different device sizes and resolutions.
- Attachments
-
- chrome_8Sh8bmkNkJ.png (5.09 KiB) Viewed 238 times
-
- chrome_b36tUgqdN4.png (3.87 KiB) Viewed 238 times
Kind regards,
<js />
<js />
Re: Radio Button Layout
Using such a Bootstrap-grid-system-based solution the result would be like this:
XS-Device
One radio per row on extra-small devices
SM-Device
Two radios on small devices
MD-Device
Three radios per row on medium devices
LG-Device
Four radios per row on large devices
This solution should be compatible with different browser- and device-environments.
Please note that uploaded images have been scaled by the forum software to fit best
XS-Device
One radio per row on extra-small devices
SM-Device
Two radios on small devices
MD-Device
Three radios per row on medium devices
LG-Device
Four radios per row on large devices
This solution should be compatible with different browser- and device-environments.
Please note that uploaded images have been scaled by the forum software to fit best
Kind regards,
<js />
<js />
Re: Radio Button Layout
Hi,
I agree. It should definitely be based on bootstrap. Here I uploaded a screencast showing horizontal positioning of 6 radiobuttons in the free survey Limesurvey ( https://limesurvey.org/ ).
Of course, if the screenspace gets to the lover ends of the different bootstrap with options, "funny" things can happen and the text breaks to a new line in unwanted places.
MP4, 400 KB: https://dl.olaf-noehring.de/?t=a8711d79 ... 2c332ee194
(can not attach MP4 and siez/width too large for image in this forum)
Olaf
I agree. It should definitely be based on bootstrap. Here I uploaded a screencast showing horizontal positioning of 6 radiobuttons in the free survey Limesurvey ( https://limesurvey.org/ ).
Of course, if the screenspace gets to the lover ends of the different bootstrap with options, "funny" things can happen and the text breaks to a new line in unwanted places.
MP4, 400 KB: https://dl.olaf-noehring.de/?t=a8711d79 ... 2c332ee194
(can not attach MP4 and siez/width too large for image in this forum)
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view