I'm also quite surprised that no one has been able to come up with a quick suggestion - I surely did not expect to be the first person ever to try and align the baseline of text of 2 different types of objects in Revolution...
I apologise for the long post, but it is better to let you know all that has been suggested and tried already, rather than letting everyone waste time covering the same ground over and over again...
PROBLEM:
I have a stack with a card where there is a display group containing a field and a button (pulldown menu). The stack is a mini-calendar. The pulldown menu button is a list of months, and the field displays the year. They sit side-by-side, so it looks as if it were just a display field. However, when the user clicks no the month name, they can select a new month from a menu. When they click on the year, they can type in a new year.
The user will be able to change the size of the display text used for the button and the field (at the same time, so both controls will always have the same size text). I want to keep the baselines of the text in the button and the field ALIGNED, so that as the user select a new text size, the field and the button resize and remain aligned, just as if it were a single display field.
TRIED ALREADY: Having the field and the button resized to their formattedHeight:
1) align tops of both objects 2) align bottoms 3) align vertical centers - 'item 2 of the loc'
Have obviously made sure that the 'margins' and the 'borderWidth' properties of both controls is the same.
INVESTIGATING:
I've noticed that even though the text, border and margins settings for both controls is the same, Revolution always reports DIFFERENT 'formattedHeights' for each - even though they both always have text at the same point size.
I've been trying to work out then just HOW Revolution has been calculating the 'formattedHeight' for the button and the field. So I conducted the following (monotonous) experiment:
1) set the field and the button's textSize to a certain number 2) recorded the reported 'formattedHeight' of both
This was done with textSizes: 7,8,9,10,11,12,14,16,18,20,24,28,32,36,48 (15 measurements)
With the field's margins set to "4" and borderWidth set to "2" with showBorder set to "false", the formattedHeights reported were: 15,16,18,19,20,22,24,27,30,32,38,43, 48,54,70.
With the button's margins set to "4", borderWidth set to "2" and showBorder set to "false", the formattedHeights reported were: 17,18,19,20,21,22,25,27,29,31,36,41,45,50,63.
We can see straight away that Revolution seems to be using a different formula for the calculation of formattedHeight for the different controls. Applying a little linear regression formula, we can see that the formula for calculating:
*** the formattedHeight of the FIELD: = trunc((textSize * 100/75) + 6)
*** the formattedHeight of the BUTTON: = round((textSize * 100/87.5) + 8.5)
So the formattedHeight WILL VARY between object types, even if the same textSize is used.
MORE CONFUSION
OK, so this might simply mean that Revolution assumes that we will need more/less white space around some object types than others. That is a fair assumption, and that would explain the different formulas.
If I set the textSize of my 2 objects to "12", however, I can see that the formattedHeight for both is actually the same ("22"). So if the textSize is 12, both objects actually have the same height, margins, borders, textSize and formattedHeight. I should be able to then perfectly align both objects, right next to each other, so that their top, bottom and vertical center (item 2 of loc) are also the same! Therefore, at that textSize, the baseline of my 2 objects should align perfectly, too.
However, the objects text baselines DO NOT ALIGN! - the field's baseline is 2 pixels higher than the button's! And that distance (2 pixels) is not constant, either. It changes at different point sizes.
VERTICAL ALIGNMENT?
Revolution handles the VERTICAL alignment of text for the button differently than for the field. If we make the button higher than it needs to be, we can see that Rev keeps the text vertically CENTRED in the button. If we make a field higher than it needs to be, Rev keeps the text TOP ALIGNED. It could be then that it's the existence of EXTRA SPACE around the text of these objects, combined with the different ways of Rev to vertically align the text, that could be causing the misalignment of baselines.
If we could, then LIMIT THE DISPLAY of the content of the object to JUST THE TEXT, removing all extra space from around it, then we should be able to finally align these objects' baselines. OK, let's try setting both objects' margins and borderWidths to '0'. And this time, instead of using the 'formattedHeight' to find out high high our objects have to be, we'll simply set them to be as high as the text (ie, height = textSize). Let's try this with textSize and height = 8...
It appears that both the field and the button have the 'edge' of the text 'cut off', at the top and at the left... The field's text is cut so far down from the top, that half the word can't be seen. And again, the baselines do NOT ALIGN.
A quick trip to the manual tells me that the margins have to be 'at least 2', otherwise unexpected behaviour will occur. My own observation is that even if the showBorder is set to 'false', the borderWidth still has to be at least 2 as well, otherwise 'unexpected behaviou' (like the edge of the text being chopped off) does indeed occur at smaller point sizes. Oh, and it doesn't matter what settings we use - the baselines will not align...
CONCLUSION - MAYBE?
When I first enquired about this alignment problem, I expected to be told that I missed something in the manual - a function, perhaps that can tell me where the baseline of the text of an object is being drawn. This seems to be a basic function, necessary for precise placement of text on the screen. I have looked many times over the documentation, but have been unable to find a way to do this (workout the precise position of the baseline of an object).
Given the formulas above, I feel that it might perhaps be possible for us to calculate WHERE the baseline of the text in the field and the button is being drawn. If that were possible, then it would also be possible to ALIGN the baselines of these objects. However, that requires a bit more observation, measurement recording, and a bit more maths than I can handle...
Would anyone out there be able to help?
Has anyone encountered this problem before - and has been able to come up with a solution?
Any suggestions for alternative ways to approach the problem?
Kind Regards,
-- Igor de Oliveira Couto ---------------------------------- [EMAIL PROTECTED] ----------------------------------
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
