Hello,
I want to add some radio buttons on a form, but how can I specify the distance between them so they will fit with the rest of the layout?
See the controls from the left, they all have 10 px as vgap, so I want the same for the radio buttons.
[attachment=0]servoy_radios.JPG[/attachment]
Thanks,
Bogdan.
Hi Bogdan,
You should be able to align them using the (top/bottom) margin properties of the radiobutton field.
Hope this helps.
Hello,
Yes, it’s working, not very well, but works. For instance, if I set the bottom to 11 and then to 12, the difference from first to the second radio button will increase with 2 pixels, instead of 1.
Thanks,
Bogdan.
Hi Robert
Do styles on Radio buttons now really work at all in a useful manner?
I can’t align a radio button in a field of height 18 px (our standard height for lists (tabel views), see screenshot. I tried all sorts of things like in the radio style defined, but no luck
/* RADIO STYLES They seems to exist since Servoy 5 (hu, 27.1.2010) */
radio
{
//font: 11pt LucidaGrande;
//text-align: left;
border-style: empty;
//margin: -2px 0px 2px 0px;
/* vertical-align and line-height do not work, hu 27.1.2010 */
vertical-align: top;
vertical-align: baseline;
line-height: 0.8;
line-height: 1.0em;
line-height: 80%;
}
May be you have the solution to it? That would be great
Regards, Robert
ROCLASI:
Hi Bogdan,You should be able to align them using the (top/bottom) margin properties of the radiobutton field.
Hope this helps.
Hi Robert,
It seems that when using the margins in the stylesheet you can’t use negative numbers. When using negative numbers in the properties pane you get the desired result.
So this seems like a bug to me.
Hi Robert
To me as well. Waiting for a Servoy response …
Regards,
ROCLASI:
Hi Robert,It seems that when using the margins in the stylesheet you can’t use negative numbers. When using negative numbers in the properties pane you get the desired result.
So this seems like a bug to me.
Hi all,
I’m having a similar problem using radio buttons along with a valuelist containing custom values. They don’t seem to want to line up vertically, and instead are offset from the left margin by amounts that seem to be related somehow to the length of the list item being displayed. I’ve tried setting margins and anchors to no effect. I found a discussion from about 5 years ago where the solution at the time was to take each item in value list and put into its own field, and align them that way, ie, if there are 4 items, use 4 value lists attached to 4 fields on the form, each one holding one value. That doesn’t seem like much of a solution, and since it was for an earlier version of Servoy, I’m hoping that there is now a better way. I would think that they should at least align vertically, but can’t figure out how to do that.
Any thoughts?
Thanks.
Ron
Hi Ron
Problem still exists, as the vertical alignment does still not work (as needed). There is also support needed for negative values which do work in the margin property on the form, but not within the css.
The horizontal alignment has a very strange formula of taking the length of the names into account, instead of allowing for proper vertical alignment. Already a very long standing problem. I really hope it is going to be enhanced soon. After all, it’s a basic HI element.
Best regards, Robert
PS: We also have snow here (in Switzerland), even in the flat land part. And it’s cold .-)
RonG:
Hi all,I’m having a similar problem using radio buttons along with a valuelist containing custom values. They don’t seem to want to line up vertically, and instead are offset from the left margin by amounts that seem to be related somehow to the length of the list item being displayed. I’ve tried setting margins and anchors to no effect. I found a discussion from about 5 years ago where the solution at the time was to take each item in value list and put into its own field, and align them that way, ie, if there are 4 items, use 4 value lists attached to 4 fields on the form, each one holding one value. That doesn’t seem like much of a solution, and since it was for an earlier version of Servoy, I’m hoping that there is now a better way. I would think that they should at least align vertically, but can’t figure out how to do that.
Any thoughts?
Thanks.
Ron
Hi Robert,
Thanks for that information. Very helpful. Do we know if Servoy is “officially” aware of these issues and has plans to implement a fix at some point? I understand that they are very busy, but it’d be helpful to know if it’s on their radar. Servoy folks?
And while we’re at it, it’d be nice to have some control over the placement of elements in Table View. Even if we could just position where the “table” is going to appear on the form. Functionally, it’s fine, but aesthetically, it leaves something to be desired.
I ended up going in an entirely different direction. The best I could do with what I understand about radio buttons resulted in something that looked, well, let’s just say, not as nice as I’d want. I ended up creating a field for each item I wanted to display and formatted it as a checkbox with an underlying global variable. The title of the element displays the description that I need the user to have, and then I use code behind the scenes to interrogate the global variable to see if it’s been set. It doesn’t have the exclusivity of radio buttons, but provides me with some flexibility instead that I use to provide some additional commentary for each item by inserting an additional label directly below each item. I’m then able to lay it out exactly as I want.
It looks good, and provides me with what I need. It’d still be good to have these other issues resolved at some point. Hopefully one of the Servoy folks here can take moment and fill us in.
Oh, and Robert, yep, snow here too, although they’re predicting near 50 degrees in a couple of days, which is really unusual and will make a mess. My sons are unhappy because it will wreck the ice on the ponds where they play hockey. I didn’t know that there any flat parts in Switzerland
Have a good day.
Ron
Hi Ron
RonG:
Hi Robert,Thanks for that information. Very helpful. Do we know if Servoy is “officially” aware of these issues and has plans to implement a fix at some point? I understand that they are very busy, but it’d be helpful to know if it’s on their radar. Servoy folks?
And while we’re at it, it’d be nice to have some control over the placement of elements in Table View. Even if we could just position where the “table” is going to appear on the form. Functionally, it’s fine, but aesthetically, it leaves something to be desired.Ron
I am not sure if aesthetical has a high priority at Servoy, may be not that much. At least what I look at pleasant collides quite from time to time with the Servoy possibilities.
RonG:
I ended up going in an entirely different direction. The best I could do with what I understand about radio buttons resulted in something that looked, well, let’s just say, not as nice as I’d want. I ended up creating a field for each item I wanted to display and formatted it as a checkbox with an underlying global variable. The title of the element displays the description that I need the user to have, and then I use code behind the scenes to interrogate the global variable to see if it’s been set. It doesn’t have the exclusivity of radio buttons, but provides me with some flexibility instead that I use to provide some additional commentary for each item by inserting an additional label directly below each item. I’m then able to lay it out exactly as I want.It looks good, and provides me with what I need. It’d still be good to have these other issues resolved at some point. Hopefully one of the Servoy folks here can take moment and fill us in.Ron
I hope so. I just do not want make workarounds, for that I keep a mail from Jan Aleman as proof that once (22.5.2005) he just said that:
Sind Sie work around-müde?
Liebe Application-Professionals,
darauf haben Sie gewartet!
…
RonG:
Oh, and Robert, yep, snow here too, although they’re predicting near 50 degrees in a couple of days, which is really unusual and will make a mess. My sons are unhappy because it will wreck the ice on the ponds where they play hockey. I didn’t know that there any flat parts in SwitzerlandHave a good day.
Ron
Ok, may be flat for what we understand as flat (others would may be say hilly
+1 … BUT let’s be reasonable here:
BOTTOM LINE: If you feel that a 1px difference is worth 5x to 15x worth your time… then that’s “fine.”
I don’t.
HOWEVER - I DO AGREE with you - that it would be NICE if Servoy would fix some of these “annoying” GUI issues!
Hi Bob,
Thanks for the comments, although the tone seems to sound as though you’re angry with me/us for some reason. It certainly wasn’t my intent to upset anyone.
I thought I’d been fairly clear that I understand that the Servoy folks are very busy. I also asked if someone could just explain why they have done the items I asked about in the way that they have. I understand about priorities; I’ve been working in IT for almost 40 years now. But, I don’t think it’s unreasonable to ask to understand why some things are done as they are. Or even to just find out if an item is on their radar or if the developerbase should be looking for another way to do things. We want Servoy to be successful, and I’m perfectly happy to assist where I can to make that happen. But, it’s a two way street and I’d love to have Servoy folk’s thoughts on this.
Regards the details of the UI, pixels sometimes matter, and sometimes they don’t. If a label is off abit amongst a group of other labels, it most likely won’t be noticed. But, because of the visual nature of radio buttons, errors in alignment are quite visible and just don’t look right. If you are in the closed environment of a large corporation, you may be able to get away with not having a clean interface, and users will live with it because they have to. But out in the world of ISVs, we have to make our products as polished as possible. I would think that vertical alignment of radio buttons would be a fairly simple task, and it may just be a matter of priorities. If the problem is with Eclipse (per your comments that closed environments such as Access being different), then let’s just say so. Then we can move on to come up with other solutions.
One of the reasons I ask these questions is because I am still fairly new to the environment, and it’s likely that I’m just not understanding many of the things yet (thus my posts that start with “The Rookie Rides Again”). So, I’m asking for information as well as understanding purposes. I don’t think that that’s asking too much. So, if my questions have sounded disrespectful in some way, that certainly wasn’t my intent. I just want to learn the best possible way to use Servoy; I think it’s the best development platform for what I want to do, and I wouldn’t be using it if I didn’t believe that.
Ron
Hi Bob
In my opinion you are mixing cause and effect. The effect is the “one pixel”, which is debatable. BUT the cause is a style sheet element which is not working properly and is by the way even inconsistent in behaviour with the forms property margin 1), AND that’s not debatable to me, except the priority of the date of fixing it - which is made by Servoy.
Best regards, Robert
PS: I’d like to point out that I usually assume we are discussing about the cause, and not the effect, which may or may not be minor or major.
bcusick:
+1 … BUT let’s be reasonable here:
- Yeah, so the alignment is “out” by ONE pixel. True. You have the screen shot to “prove it.”
- Can it be “better” - yeah, of course!
- Should you expect “perfection” from your software vendor (in the way you think of “perfection”) - ummmmm… nope. It depends what you’re “used to” developing with. If you have a 100% CLOSED environment (FoxPro, Access, FileMaker Pro) - then, yeah, there is a difference.
- DEAL WITH IT.
Seriously - If you were developing your solution in ANYTHING else - you would spend 5x to 10x the time.
BOTTOM LINE: If you feel that a 1px difference is worth 5x to 15x worth your time… then that’s “fine.”
I don’t.
HOWEVER - I DO AGREE with you - that it would be NICE if Servoy would fix some of these “annoying” GUI issues!
I assume the relevant cases have been created already in the support system, with sample solutions where applicable?
Paul
You assume correctly, Paul, I entered this into the Support System as case no 194239, in there since Version 4.1.0!
Einen guten Rutsch in’s neue Jahr und alles Gute für’s 2011!
Best regards, Robert
pbakker:
I assume the relevant cases have been created already in the support system, with sample solutions where applicable?Paul
Hi Robert,
I checked out that case you mentioned, but that case doesn’t say anything about negative values not working for margins through StyleSheets.
Furthermore, the case was checked, but the engineer couldn’t reproduce it, so he asked for a sample solutions, which, as far as I can see, was never supplied.
Paul
Hi Paul
Happy 2011 to you and all the best for the new year!
I did not mention the negative values because I don’t think using negative values is the correct solution - I just found with the margin property on the form that with negative values I can adjust an element further - if that’s really the intended behaviour is very questionable I think.
I allow for such an easily reproducable behaviour not to make a solution, it can be checked in any solution at hand. There are 2 screenshots in the thread which, in my opinion, leave nothing open to see what’s the problem (for 2 different platforms). Don’t you think so?
By the way, by accident, we found out that if the margin property values on a form are set, the style for this element is completely ignored! Depending on how you see it that’s quite dangerous in the sense that one doesn’t may be realize this “logic” for a very long time, leading to some hours of debugging (in our case), as there is never a warning given to indicate that precedence is applied to the element. Are there other such precedences with styles and form properties, i. e. the form property overrides the style? To me, it should be the opposite, i. e. the cascading style if present should always win.
Regards,
pbakker:
Hi Robert,I checked out that case you mentioned, but that case doesn’t say anything about negative values not working for margins through StyleSheets.
Furthermore, the case was checked, but the engineer couldn’t reproduce it, so he asked for a sample solutions, which, as far as I can see, was never supplied.
Paul
design time properties on elements/forms are always overwriting the css specified things.
Else it wouldn’t make any sense to set them in the first place.
You have default values (of the look and feel), css values and designer property values
the are applied on top of each other in that order, so designer values always win. This way you can overwrite specific things for that specific element.
Hi Robert,
Happy new year to you as well.
The engineer that handled your case wasn’t able to reproduce your findings, so apparently just screenshots aren’t enough to reproduce it.
As for the StyleSheet vs. Form/Element properties: Form/element level property settings take priority over StyleSheet settings. This has always been the case (and works consistently AFAIK).
I don’t think it should be the other way around, as the current behavior allows you to “customize” a specific element on element level. otherwise you’d have to create many styles used on only one element to get things done.
Paul
Hi Paul
pbakker:
Hi Robert,Happy new year to you as well.
The engineer that handled your case wasn’t able to reproduce your findings, so apparently just screenshots aren’t enough to reproduce it.
I really can’t believe that, as this behaviour exist since Servoy version 4 and is reproducable on any table view having for example a field height of 18 px, but if I find time I will make an example, but would be very happy if the engineer could give it again a quick try in one of his table views.
pbakker:
As for the StyleSheet vs. Form/Element properties: Form/element level property settings take priority over StyleSheet settings. This has always been the case (and works consistently AFAIK).I don’t think it should be the other way around, as the current behavior allows you to “customize” a specific element on element level. otherwise you’d have to create many styles used on only one element to get things done.
Paul
I agree, from the perspective of “a mixed mode approach” it seems logical to have it that way.
Regards,
