s 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 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
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
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
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
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
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
ations 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.
>>
>> 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 th
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 make it scroll
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 group
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 well on mobile. I
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 instea
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...@hyperactivesw.com
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
___
use
> From: use-livecode [mailto: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
>
> Th
...@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 found some
h 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 or a
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
rWidth,
> 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 calculated “disregarding margins.”
>
> That does
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
On Thu, Nov 10, 2016 at 1:39 PM, J. Landman Gay <jac...@hyperactivesw.com>
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 accomod
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 same
number
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
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 fine
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?
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 really
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 really want to use my larger font 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
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 24, and I
have 1043 lines in my field, that the
Height of my field using FormattedHeight
equals 33,390 which
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
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
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
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 24, and I
have 1043 lines in my field, that the
Height of my field using FormattedHeight
equals 33,390 which apparently goes
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? :-)
Thanks
Hi Chris,
On Mon, Apr 9, 2012 at 11:55 PM, Chris Sheffield cmsheffi...@me.com 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
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? :-)
Have a look to the dgFormattedHeight property in the datagrid API
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
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 IMAGE WITH ALPHADATA
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.
Instead
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 could use formattedheight and
formattedwidth to do this but it doesn't seem to be working.
I'm very perplexed too
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
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 b...@twft.com wrote:
If you have ever had to edit type faces
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 it to a SQL
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 b...@twft.com 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
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 mailing list
use
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 size of the text
. 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.
The *formattedHeight* of a chunk in a field
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* property
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 on a Mac the focusborder also added
---
www.designeq.com
On Wed, Feb 16, 2011 at 3:37 PM, BNig niggem...@uni-wh.de wrote:
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
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
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:
set
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
do it, suitably adjusted to account for margins on each side of the card
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
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
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 measurement is the amount of space
occupied by all visible objects on the card. It is calculated from
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,
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
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
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
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 confused
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 (Dictionary).
I don't think you can
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 jumps
69 matches
Mail list logo
