e a bug with formattedWidth and
> formattedHeight of a field in android. I’m attempting to maximize (without
> clipping) the textSize of a string in a fixed-size field. I have code that
> works reliably in the IDE and on iOS but not on android. My use case seems to
> be solvable by first
I’ve recently run into what feels like a bug with formattedWidth and
formattedHeight of a field in android. I’m attempting to maximize (without
clipping) the textSize of a string in a fixed-size field. I have code that
works reliably in the IDE and on iOS but not on android. My use case seems
It's do-able though it requires some study. But it works very well and solves
the problem.
On 5/4/20 3:01 PM, scott--- via use-livecode wrote:
Good to know that Trevor’s work was able to solve this problem! (Sounds as if
it may not be a solution for the faint of heart yet.)
—
Scott
On May 4,
Good to know that Trevor’s work was able to solve this problem! (Sounds as if
it may not be a solution for the faint of heart yet.)
—
Scott
> On May 4, 2020, at 11:04 AM, J. Landman Gay via use-livecode
> wrote:
>
> On 5/2/20 12:25 PM, J. Landman Gay via use-livecode wrote:
>> I think the solu
On 5/2/20 12:25 PM, J. Landman Gay via use-livecode wrote:
I think the solution has to be in the engine. I'm in trouble.
I am no longer in trouble. :) Huge thanks to Trevor for spending an inordinate amount of time
with me over the weekend to get his DataView working in my stack. It's really a
J. Landman Gay wrote:
> On 5/2/20 8:20 PM, Richard Gaskin via use-livecode wrote:
>> LiveCode is nearly unmatched for making desktop apps, but for
>> mobile development there are so many unfinished edges it's barely
>> a contender for anyone not already heavily invested in LiveCode
>> from deskto
I agree that that’s what Widgets are for, but I don’t think there’s been enough
input from the mother ship to ensure that all published widgets look as much as
possible like ‘normal’ LC objects, with the expected properties and full
documentation. Obviously some are very powerful and useful and
On 5/2/20 8:20 PM, Richard Gaskin via use-livecode wrote:
LiveCode is nearly unmatched for making desktop apps, but for mobile development there are so
many unfinished edges it's barely a contender for anyone not already heavily invested in
LiveCode from desktop work.
It would be reassuring if
J. Landman Gay wrote:
> I think the solution has to be in the engine. I'm in trouble.
Even if you find a workaround, I hope the engine team understands that
it's a workaround, and has interest in letting us work in ways that are
far less strangely counterintuitive that having to wrap a field i
oup combinations in the stack and they all work except this one,
>> but the others are all shorter.
>>
>> I set the inner field to its full formattedHeight inside the group, which
>> is shorter. The group has a behavior that scrolls the content.
>&g
this one,
>> but the others are all shorter.
>>
>> I set the inner field to its full formattedHeight inside the group,
which
>> is shorter. The group has a behavior that scrolls the content.
>>
>> I discovered today that if I set the beha
they all work except this one,
but the others are all shorter.
I set the inner field to its full formattedHeight inside the group, which
is shorter. The group has a behavior that scrolls the content.
I discovered today that if I set the behavior on the field instead of its
enclosing group, I can
t;>> acceleratedRendering on mobile. The same setup is used for all the
>>> field/group combinations in the stack and they all work except this one,
>>> but the others are all shorter.
>>>
>>> I set the inner field to its full formattedHeight inside the
o its full formattedHeight inside the group, which
is shorter. The group has a behavior that scrolls the content.
I discovered today that if I set the behavior on the field instead of its
enclosing group, I can make it scroll. But acceleratedRendering on a field
is jerky and doesn't work very we
they all work except this one, but
> the others are all shorter.
>
> I set the inner field to its full formattedHeight inside the group, which is
> shorter. The group has a behavior that scrolls the content.
>
> I discovered today that if I set the behavior on the field inst
s are all shorter.
I set the inner field to its full formattedHeight inside the group, which is shorter. The group
has a behavior that scrolls the content.
I discovered today that if I set the behavior on the field instead of its enclosing group, I
can make it scroll. But acceleratedRendering
...@elementarysoftware.com
booth1-800-615-0867
--
> On May 1, 2020, at 1:17 PM, J. Landman Gay via use-livecode
> wrote:
>
> Is the formattedHeight of a group broken for anyone else? LC 9.6dp4 (and
> possibly dp3).
>
>
via use-livecode
Sent: Friday, May 01, 2020 4:17 PM
To: LiveCode Mailing List
Cc: J. Landman Gay
Subject: FormattedHeight
Is the formattedHeight of a group broken for anyone else? LC 9.6dp4 (and
possibly dp3).
I'm a little frantic.
--
Jacqueline Landman Gay | jac...@hyperactives
Is the formattedHeight of a group broken for anyone else? LC 9.6dp4 (and
possibly dp3).
I'm a little frantic.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
__
ailto:use-livecode-boun...@lists.runrev.com] On Behalf
> Of David Epstein via use-livecode
> Sent: Friday, February 02, 2018 9:38 PM
> To: use-livecode@lists.runrev.com
> Cc: David Epstein
> Subject: Re: FormattedHeight of a field and its contents
>
> Thanks for the responses on
ecode-boun...@lists.runrev.com] On Behalf Of
David Epstein via use-livecode
Sent: Friday, February 02, 2018 9:38 PM
To: use-livecode@lists.runrev.com
Cc: David Epstein
Subject: Re: FormattedHeight of a field and its contents
Thanks for the responses on this. I used Bernd’s tool and did some more tests,
and
avoids
clipping the content. With horizontal gridlines visible, a 6 pixel buffer
makes the top row the same height as the other rows. And with a 6 pixel buffer
the formattedHeight of the field will exactly match the formattedHeight of the
field's content (although a non-zero borderwidth
Epstein via use-livecode wrote:
> Is there somewhere an explanation of how a field’s textSize, borderWidth,
> margins, and formattedHeight interact?
>
> According to the dictionary entry for “formattedHeight”, a field’s
> formattedHeight is calculated “including top and bottom marg
I get 14 for line 1 and 22 for the field. Put that in your smipe and poke it!
;-)
Bob S
> On Jan 31, 2018, at 17:31 , David Epstein via use-livecode
> wrote:
>
> Is there somewhere an explanation of how a field’s textSize, borderWidth,
> margins, and formatted
Hi David,
have a look at
http://berndniggemann.on-rev.com/margins/marginsapp.livecode.zip
It does not explain why but shows what influences the formattedHeight of a
field when changing margins, border size, scrollbars, text height etc.
Kind regards
Bernd
--
Sent from:
http://runtime
Is there somewhere an explanation of how a field’s textSize, borderWidth,
margins, and formattedHeight interact?
According to the dictionary entry for “formattedHeight”, a field’s
formattedHeight is calculated “including top and bottom margins”, while the
formattedHeight of a chunk is
On Thu, Nov 10, 2016 at 1:39 PM, J. Landman Gay
wrote:
> Interesting...I'm working with formattedheight today too. I have a field
> placed under an image where it can't be seen. It slides down sometimes and
> moves everything below it down to accomodate. When I get the
>
Interesting...I'm working with formattedheight today too. I have a field
placed under an image where it can't be seen. It slides down sometimes
and moves everything below it down to accomodate. When I get the
formattedheight of the group the controls are in, it returns the sa
Is 8 ignoring margins in calculating formattedHeight?
Placing a single line of text into a field, which is Helvitica Bold size 9,
and margins of 0,6,0,0, it manages to return a formattedHeight of 7 when
checking . . .
uhh . . . .
Am I missing something here?
This worked for years in 5/7 for
There seems to be a problem with the formattedHeight property of a button.
I'm assigning an icon to the button and leaving the showName property to
true. By doing that, I can make the button high enough so that the button
name shows under the icon.
The formattedwidth property seems to work
Hi Dan,
I have several fields on one card so I don't want the field to display
on the entire card, as it ruins everything else. I understand you
are trying to use that as an example, but other than the display what
should I be setting the rect to if not the size of the contents for scrolling?
It
d field for your iOS scroller,
>> but rather scroll the field itself. In your scrollerDidScroll message,
>> scroll the field, not the scroll of the group. This is what I use when I
>> suspect the FormattedHeight may be larger than the allowable range.
>>
>>
Obvious maybe, but why not just remove the first several lines when past the
half way mark to the bottom of the field and vice versa when going up to the
beginning of the field…
Thomas J McGrath III
3mcgr...@comcast.net
Lazy River Software
http://lazyriver.on-rev.com
On Aug 6, 2012, at 9:
Hi Bob,
The limit will keep the script from blowing up, but then the field won't
display all of the data.
The last several lines are cut off from the display.
Thanks anyways,
Rick
On Aug 6, 2012, at 8:15 PM, Bob Sneidar wrote:
> set the height of field "ViewingField5" of this card to max(tHe
set the height of field "ViewingField5" of this card to max(tHeight5, 32768)
will that work?
Bob
On Aug 6, 2012, at 4:57 PM, Rick Harrison wrote:
> set the height of field "ViewingField5" of this card to tHeight5
___
use-livecode mailing list
use-l
up. This is what I use when I suspect
> the FormattedHeight may be larger than the allowable range.
>
> Hope that helps!
>
> -Dan
>
>
>> Hi there,
>>
>> I discovered that if I'm using large text
>> in my scrolling field of size
Rick,
One thought is to not use scroll the grouped field for your iOS scroller, but
rather scroll the field itself. In your scrollerDidScroll message, scroll the
field, not the scroll of the group. This is what I use when I suspect the
FormattedHeight may be larger than the allowable range
ed that if I'm using large text
> in my scrolling field of size 24, and I
> have 1043 lines in my field, that the
> Height of my field using FormattedHeight
> equals 33,390 which apparently goes
> beyond a limit of 32,768 and causes
> an unreported error in the iOS Simulator
Hi there,
I discovered that if I'm using large text
in my scrolling field of size 24, and I
have 1043 lines in my field, that the
Height of my field using FormattedHeight
equals 33,390 which apparently goes
beyond a limit of 32,768 and causes
an unreported error in the iOS Simulator.
I r
Thank you! I figured it had to be there somewhere. Missed it on my first pass
through the docs.
On Apr 9, 2012, at 4:34 PM, zryip theSlug wrote:
> Hi Chris,
>
> On Mon, Apr 9, 2012 at 11:55 PM, Chris Sheffield wrote:
>> I'm trying to set the height of a data grid based on
Hi Chris,
On Mon, Apr 9, 2012 at 11:55 PM, Chris Sheffield wrote:
> I'm trying to set the height of a data grid based on the formattedHeight
> property, but as far as I can tell, the formattedHeight of a data grid
> returns the height. Is this a bug or by design? If by design,
I'm trying to set the height of a data grid based on the formattedHeight
property, but as far as I can tell, the formattedHeight of a data grid returns
the height. Is this a bug or by design? If by design, is there some other way I
can accomplish this? Trevor, are you listening? :-)
T
urns the bounding rect of the actual letters in the field
-- which is different from the formattedRect
-- based on a script by Scott Rossi
--
http://runtime-revolution.278305.n4.nabble.com/What-is-up-with-FormattedHeight-tt4360344.html#a4372671
lock screen
## CREATE IM
Actually, I may be wrong but I seem to recall the script I posted being a
variation of something written by Trevor DeVore. Just to keep the credits
rolling along...
Regards,
Scott Rossi
Creative Director
Tactile Media, UX Design
Recently, Howard Bornstein wrote:
> Wow, thank you Ken and Scott
xtRect
>
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX Design
>
>
>
>
>
> Recently, Ken Corey wrote:
>
> > On 06/02/2012 03:30, Howard Bornstein wrote:
> >> I need to find the smallest rectangle that will enclose a
xtRect
Regards,
Scott Rossi
Creative Director
Tactile Media, UX Design
Recently, Ken Corey wrote:
> On 06/02/2012 03:30, Howard Bornstein wrote:
>> I need to find the smallest rectangle that will enclose a line of text of
>> arbitrary text size in a field. I thought I coul
On 06/02/2012 03:30, Howard Bornstein wrote:
I need to find the smallest rectangle that will enclose a line of text of
arbitrary text size in a field. I thought I could use formattedheight and
formattedwidth to do this but it doesn't seem to be working.
I'm very perplexed too.
That makes sense. I was complaining about formattedHeight for fields. For
buttons it seems useful.
On Wed, Feb 8, 2012 at 2:26 PM, Bob Sneidar wrote:
> One thing I use it for is programmatically setting the height of menu
> buttons. I find the default size to be too large for a busy form
One thing I use it for is programmatically setting the height of menu buttons.
I find the default size to be too large for a busy form, so I set the height to
the formattedHeight of the text of the button. I have a utility that "drops" a
field, button or menu onto a card and links i
Right. As I've been able to determine, the textheight is used to create the
leading and the formattedheight uses the font metrics, the textheight (if
set) and the field margins (if set).
On Mon, Feb 6, 2012 at 9:09 AM, Bob Sneidar wrote:
> If you have ever had to edit type faces, you w
Thanks for your reply. As a graphic designer, I know about ascenders,
descenders, x-height, etc. However, I had thought that formattedHeight
adjusted the field height to the size of the text being displayed, not to
the min and max of the entire type face.
I created a field with the entire
e in a field. I thought I could use formattedheight and
> formattedwidth to do this but it doesn't seem to be working.
>
> The dictionary says about FormattedHeight:
>
> Use the *formattedHeight* property to determine how much vertical space an
> object needs.
>
> Th
Howard,
> Why doesn't the formattedHeight of a field just do this automatically? Why
> does it include extra space at the top and bottom of the field?
> What are the relationships among text size, text height, and field height
> that will allow the field to adjust to exactly the
de (v1.4.1 released 26/08/2011)
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/What-is-up-with-FormattedHeight-tp4360344p4360697.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-livecode mailin
I need to find the smallest rectangle that will enclose a line of text of
arbitrary text size in a field. I thought I could use formattedheight and
formattedwidth to do this but it doesn't seem to be working.
The dictionary says about FormattedHeight:
Use the *formattedHeight* proper
Hi Howard,
I've sent you the stack and here it is for anyone interested in playing
around with the parameters of a field that affect the formattedHeight of
that field.
http://berndniggemann.on-rev.com/margins/marginsapp.livecode.zip
Kind regards
Bernd
On Wed, Feb 1, 2012 at 1:
>
> --
> Regards,
>
> Howard Bornstein
> ---
> www.designeq.com
>
>
> On Wed, Feb 16, 2011 at 3:37 PM, BNig wrote:
>
>>
>> Hi Claus,
>>
>> I made a little revlet that shows what impacts the formattedHeight of a
>> field:
>>
>>
what impacts the formattedHeight of a
> field:
>
> http://berndniggemann.on-rev.com/marginsrevlet/
>
> among other things the scrollbars and their size furthermor the margins,
> the
> borderwith the textsize and the textheight. I hope I did not forget
> anything. Before 4.5 o
those numbers or remember to set the stack height and width so I
> started looking for a generic method which I could put in the stack script
> and I'd never have to worry about changing it again.
>
> The formattedheight and formattedwidth properties ended up being the way to
>
looking for a generic method which I could put in the stack script
and I'd never have to worry about changing it again.
The formattedheight and formattedwidth properties ended up being the way to
do it, suitably adjusted to account for margins on each side of the card.
The code I now use is:
se
Pete wrote:
OK I see what you mean about the formatted versions of height/width. The
straight height and width properties don't seem to come anywhere close to
working even allowing for menu bar issues (I'm on OS X). They set the
height/width to what they were for the previous card opened in the
Yep, that's what I was doing initially but was looking for a way to make it
happen without actually knowing the height and width.
I think I have this working now. I made sure that the topmost control on
each card always had it's topleft set to 10,10 , then I add 20 to each of
the formatted height
On 26.06.2011 at 17:42 Uhr -0700 Pete apparently wrote:
I think I will have to use the formatted height and width and be consistant
about how much room is around the borders of the controls on each card.
If your cards vary in size but are static, that is not changed
dynamically by users, the
n) when it says:
>>
>> If you specify a card or group, the *formattedHeight* reports the
>> height of a rectangle that includes all objects in that card or group
>> whose
>> visible property is true.
>>
>
> It seems accurate to me. The formatted measurem
On 6/26/11 2:52 PM, Pete wrote:
Thanks. I guess the dictionary is misleading (yet again) when it says:
If you specify a card or group, the *formattedHeight* reports the
height of a rectangle that includes all objects in that card or group whose
visible property is true.
It seems
Thanks. I guess the dictionary is misleading (yet again) when it says:
If you specify a card or group, the *formattedHeight* reports the
height of a rectangle that includes all objects in that card or group whose
visible property is true.
I tried this:
set the height of this stack to
On 6/25/11 2:17 PM, Pete wrote:
I have a number of cards in the same substack that need to be displayed with
different heights and widths. In the preOpenStack handlerr, I have:
set the height of this stack to the formattedheight of this card
set the width of this stack to the formattedwidth of
I have a number of cards in the same substack that need to be displayed with
different heights and widths. In the preOpenStack handlerr, I have:
set the height of this stack to the formattedheight of this card
set the width of this stack to the formattedwidth of this card
The height and width
Fixed with 4.6.0-dp-6.
http://quality.runrev.com/qacenter/show_bug.cgi?id=9404
We can now use the formattedHeight (or Width) reliably to decide if a
field needs scrollbars or not.
Regards,
Claus.
Am 16.02.11 22:03, schrieb Claus Dreischer:
> Hi,
>
> I'm a bit con
ght from the formattedHeight.
The height of the filed does not change, so either you subtract the
scrollbarwidth from the height of the field, or you add the
scrollbarwidth to the formattedHeight to get "the height needed by an
object to display its full contents without scrolling" (Dicti
A fun revlet.
The way you made it, it can be seen that a horizontal scrollbar not only takes
up its own height, but intrudes that amount into the lower part of the field as
well. That is why it takes twice its height from the formattedHeight.
But when I just add a hor scrollbar to a field
Hi Claus,
I made a little revlet that shows what impacts the formattedHeight of a
field:
http://berndniggemann.on-rev.com/marginsrevlet/
among other things the scrollbars and their size furthermor the margins, the
borderwith the textsize and the textheight. I hope I did not forget
anything
Hi,
I'm a bit confused with the formattedHeight of a field and an additional
scrollbar:
The content of a field has the formattedHeight of e.g. 74
The scrollbarwidth is set to 10, but the hScrollbar is not enabled yet.
Now when i enable the hScrollbar,
the formattedHeight of that field jum
73 matches
Mail list logo
