subject:"RE\: FormattedHeight"

Re: formattedHeight formattedWidth on android

2020-09-21 Thread scott--- via use-livecode

Hmm… Well now I can’t reproduce the issue that consumed a fair number of hours 
yesterday. Which, (with the exception of lost hours) is a very good thing.
—
Scott Morrow

> On Sep 20, 2020, at 7:11 PM, scott--- via use-livecode 
>  wrote:
> 
> 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 to 
> be solvable by first calculating  the amount it is likely to be off and then 
> factoring that in. It seems that there might be some related issues in 
> Bugzilla but I didn’t find anything exactly the same. I’m somewhat new to 
> Android so I always wonder if my stumbles are known limitations that I just 
> can’t find the documentation for.
> 
> --
> Scott Morrow
> 
> Elementary Software
> (Now with 20% less chalk dust!)
> web   https://elementarysoftware.com/
> email sc...@elementarysoftware.com
> --
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-04 Thread J. Landman Gay via use-livecode


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, 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 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 marvel.

I can't describe how grateful I am to him for getting me out of an 
uncomfortable situation. He's smart, patient, and so very helpful even after my 
brain fuzzed over at oh-my-god o'clock in the wee hours of the morning.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-04 Thread scott--- via use-livecode

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 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 marvel.
> 
> I can't describe how grateful I am to him for getting me out of an 
> uncomfortable situation. He's smart, patient, and so very helpful even after 
> my brain fuzzed over at oh-my-god o'clock in the wee hours of the morning.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-04 Thread J. Landman Gay via use-livecode


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 marvel.


I can't describe how grateful I am to him for getting me out of an uncomfortable situation. 
He's smart, patient, and so very helpful even after my brain fuzzed over at oh-my-god o'clock 
in the wee hours of the morning.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-03 Thread Richard Gaskin via use-livecode

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 desktop work.
>>
>> It would be reassuring if the LC team could share with us their
>> plan to finish their mobile implementation, to deliver a user
>> experience on par with its best-of-breed desktop workflows.
>
> That's what widgets are for.

Are they?

Widgets are great for specialized functionality not in the box.  But 
crafting custom widgets should not be seen as a replacement for 
essential common GUI elements.

Will you be solving your field display issue by writing your own text 
engine from scratch in a lower-level scripting language?

Should I tell that forum user that LiveCode doesn't provide common GUI 
essentials out-of-the-box?

Show of hands: how many of you would be using LiveCode today if the 
desktop editions required you to write your own common GUI controls from 
scratch?

> There are native fields and buttons, though some are still
> missing, but not enough people are writing them. And unfortunately,
> mobile GUIs change often enough on both Android and iOS that the
> native buttons aren't so native any more.

If/when this goes in the engine, it could be handled as it is on the 
desktop, with hooks into the host OS renderer.  Write once, render anywhere.

But at the moment, at a minimum the team could do what so many of us 
have done: write a library that walks through LC-native controls on the 
card and makes appropriate replacements/additions where needed for mobile.

When the script sees a group or field with scrollbars, it turns the 
scrollbars off so they're not visible and automatically creates the 
mobile-native scoller region to match it.

When the script sees a checkbox, it hides that and instantiates a 
mobile-native Boolean selector.

When the script sees an editable field, it hides that and creates an 
editable field matching those properties in its place.

Pinch-to-zoom on images becomes a property, so those interactions invoke 
a good-but-difficult-to-find-buried-in-the-forums-script to handle that 
(the Lesson on that is woefully incorrect).

In each case, message handlers route mobile-native messages to their 
LC-native counterparts.  This lets you script using LC objects without 
having to type out control defs in code like you're a C programmer from 
1993.  And it lets you enjoy one of the finest benefits of The xTalk 
Way: blurring the line between development and runtime so you spend more 
time developing your app in the environment designed for developing.

This won't handle all possible circumstances, but will remove the most 
serious pain points from at least 80% of LC's uniquely odd mobile 
development workflows.

This could be done today.  It could have been done many years ago.  Many 
of us have been replicating this for years.

That would reduce the most common pain points, but still wouldn't 
address your need to scroll field text whose formatted height exceeds 
32765px.

For that we need some engine work, to finally be done with the 
frankly-bizarre requirement that a perfectly good field needs to be 
wrapped inside of a group just to scroll smoothly.

We don't need that strange and unpredictable extra step on the desktop, 
and that we need it on mobile is not a feature, it's a bug, a 
shortcoming that I hope the engine team has a plan to address.

LiveCode on the desktop is flippin' awesome.  LiveCode on mobile can be 
every bit as awesome, and needs to be if it's to remain relevant in a 
world of simpler competitors.

The current workflow requirements undo the otherwise-powerful benefits 
of using LC on mobile for many newcomers.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web

 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-03 Thread Graham Samuel via use-livecode

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 amount to nice 
little bits of software one can slip into a program, like for example the  
browser or even the clock - but some are so mysterious that they are unusable. 
Heather recently told me that there is some hidden documentation and examples 
of some of the ‘Mg' series, which seems kind of ludicrous. 

But my main point is that anything which ends up appearing on a screen should 
have all the usual properties like colours, tooltips etc - several of the 
things that I’ve been trying to use lack the most simple properties and 
therefore seem very ‘foreign’, which surely is counter-productive. As I see it, 
widgets are intended to be a way of integrating new objects and capabilities 
into LC without needing changes in the engine. I think that the technical 
foundation is good but the implementation and presentation up to now is not 
sufficiently mature.

Just my two locked-down Eurocents.

Graham

> On 3 May 2020, at 06:42, J. Landman Gay via use-livecode 
>  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 desktop work.
>> It would be reassuring if the LC team could share with us their plan to 
>> finish their mobile implementation, to deliver a user experience on par with 
>> its best-of-breed desktop workflows.
> 
> That's what widgets are for. There are native fields and buttons, though some 
> are still missing, but not enough people are writing them. And unfortunately, 
> mobile GUIs change often enough on both Android and iOS that the native 
> buttons aren't so native any more.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-02 Thread J. Landman Gay via use-livecode


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 the LC team could share with us their plan to finish their mobile 
implementation, to deliver a user experience on par with its best-of-breed desktop workflows.


That's what widgets are for. There are native fields and buttons, though some are still 
missing, but not enough people are writing them. And unfortunately, mobile GUIs change often 
enough on both Android and iOS that the native buttons aren't so native any more.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-02 Thread Richard Gaskin via use-livecode


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 in a group.


Same with buttons (why do we have five different ways to make one 
control type), and so many things on mobile.


Yesterday in the forums a new user was asking about copy and paste on 
mobile, something we understand doesn't work with LC's built-in fields 
(along with a good many other things), but new users expect LC to behave 
as well with mobile development as it does for desktop, and the need to 
type out control definitions like we're C programmers stuck in 1993 
while using what is supposed to be be an easy drag-n-drop GUI was barely 
acceptable as a short-term workaround when LC first jumped into mobile, 
and now a decade later it's maddeningly mystifying.


So I tried to explain the situation as nicely as I could:

LiveCode's built-in field object have not yet been expanded
to integrate with mobile OSes as it does on desktop platforms.

In addition to clipboard support, you'd eventually discover other
shortcomings using those on mobile, including nonstandard UI for
text selection.

LiveCode does offer support for mobile-native fields, however,
using the script interface described in the User Guide and this
lesson:

http://lessons.livecode.com/m/4069/l/29112-how-do-i-use-native-text-controls-on-mobile


To which this new customer replied:

   Right, so that's sorted by using a native input, and letting the OS
   deal with text and copying.

   That feels like quite an awkward solution for a paid license of a
   product with heavy focus on mobile development, but it did solve
   the problem at hand, thanks for the info FourthWorld


I agree with him. It is at best awkward.

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 the LC team could share with us their plan to 
finish their mobile implementation, to deliver a user experience on par 
with its best-of-breed desktop workflows.


If that's not a goal that's useful to know as well.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-02 Thread J. Landman Gay via use-livecode

I wish, but no. I need to highlight selections in different colors, overlay 
controls, format text, extract text, and other things that are easy in 
fields but hard in a browser.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On May 2, 2020 7:31:36 PM Terry Judd via use-livecode 
 wrote:



Could you use a browser instance instead of a field?

On 03/05/2020, 03:27, "use-livecode on behalf of J. Landman Gay via 
use-livecode" use-livecode@lists.runrev.com> wrote:


   I think the solution has to be in the engine. I'm in trouble.

   --
   Jacqueline Landman Gay | jac...@hyperactivesw.com
   HyperActive Software | http://www.hyperactivesw.com
   On May 2, 2020 2:27:53 AM scott--- via use-livecode
wrote:

   > I’ve run into that a few times but not recently. I couldn’t find anywhere
   > that I had worked around it. All I can imagine trying is
   > 1. Swapping text in and out at some point (possibly just one giant 
   stutter) or

   > 2. Changing the size of the text that is not visible during the scroll…
   > though (the more I think about that one the more it seems like it would
   > make the scroll wacky in other ways)  Neither seems super-promising but
   > that’s all I can think of at the moment. If you find a solution, I would
   > love to know what it is.
   > —
   > Scott
   >
   >
   >> On May 1, 2020, at 10:24 PM, J. Landman Gay via use-livecode
   >>  wrote:
   >>
   >> Yes, that seems to be the problem. I have a long text field that exceeds
   >> the maximum. There's an enclosing group to be compatible with
   >> 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, 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 can't break up the text,
   >> it has to be all one block. I have tried setting the group to container
   >> layermode without success.
   >>
   >> If you're wondering why the text exceeds the maximum, this is for a mobile
   >> app and there is not only a lot of heavy formatting with large headings 
and
   >> spaceBelow, but the text size is largish so that it is readable on a tiny
   >> phone. That makes the pixel count pretty high.
   >>
   >> I only have a very short time left to solve this.
   >>
   >> On 5/1/20 4:45 PM, scott--- via use-livecode wrote:
   >>> Are you exceeding the maximum vertical scroll?
   >>> (I haven’t run into this recently but I believe at one point the vScroll 
of
   >>> groups was limited at the engine level to 32780)
   >>> Scott Morrow
   >>> Elementary Software
   >>> (Now with 20% less chalk dust!)
   >>> web   https://elementarysoftware.com
   >>> email sc...@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).
   
    I'm a little frantic.
   
    --
    Jacqueline Landman Gay | jac...@hyperactivesw.com
    HyperActive Software   | http://www.hyperactivesw.com
   
    ___
    use-livecode mailing list
    use-livecode@lists.runrev.com
    Please visit this url to subscribe, unsubscribe and manage your
    subscription preferences:
    http://lists.runrev.com/mailman/listinfo/use-livecode
   >>> ___
   >>> use-livecode mailing list
   >>> use-livecode@lists.runrev.com
   >>> Please visit this url to subscribe, unsubscribe and manage your
   >>> subscription preferences:
   >>> http://lists.runrev.com/mailman/listinfo/use-livecode
   >>
   >>
   >> --
   >> Jacqueline Landman Gay | jac...@hyperactivesw.com
   >> HyperActive Software   | http://www.hyperactivesw.com
   >>
   >>
   >> ___
   >> use-livecode mailing list
   >> use-livecode@lists.runrev.com
   >> Please visit this url to subscribe, unsubscribe and manage your
   >> subscription preferences:
   >> http://lists.runrev.com/mailman/listinfo/use-livecode
   >
   >
   > ___
   > use-livecode mailing list
   > use-livecode@lists.runrev.com
   > Please visit this url to subscribe, unsubscribe and manage your
   > subscription preferences:
   > http://lists.runrev.com/mailman/listinfo/use-livecode




   ___

Re: FormattedHeight

2020-05-02 Thread Terry Judd via use-livecode

Could you use a browser instance instead of a field?

On 03/05/2020, 03:27, "use-livecode on behalf of J. Landman Gay via 
use-livecode"  wrote:

I think the solution has to be in the engine. I'm in trouble.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On May 2, 2020 2:27:53 AM scott--- via use-livecode 
 wrote:

> I’ve run into that a few times but not recently. I couldn’t find anywhere 
> that I had worked around it. All I can imagine trying is
> 1. Swapping text in and out at some point (possibly just one giant 
stutter) or
> 2. Changing the size of the text that is not visible during the scroll… 
> though (the more I think about that one the more it seems like it would 
> make the scroll wacky in other ways)  Neither seems super-promising but 
> that’s all I can think of at the moment. If you find a solution, I would 
> love to know what it is.
> —
> Scott
>
>
>> On May 1, 2020, at 10:24 PM, J. Landman Gay via use-livecode 
>>  wrote:
>>
>> Yes, that seems to be the problem. I have a long text field that exceeds 
>> the maximum. There's an enclosing group to be compatible with 
>> 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, 
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 can't break up the 
text, 
>> it has to be all one block. I have tried setting the group to container 
>> layermode without success.
>>
>> If you're wondering why the text exceeds the maximum, this is for a 
mobile 
>> app and there is not only a lot of heavy formatting with large headings 
and 
>> spaceBelow, but the text size is largish so that it is readable on a 
tiny 
>> phone. That makes the pixel count pretty high.
>>
>> I only have a very short time left to solve this.
>>
>> On 5/1/20 4:45 PM, scott--- via use-livecode wrote:
>>> Are you exceeding the maximum vertical scroll?
>>> (I haven’t run into this recently but I believe at one point the 
vScroll of 
>>> groups was limited at the engine level to 32780)
>>> Scott Morrow
>>> Elementary Software
>>> (Now with 20% less chalk dust!)
>>> web   https://elementarysoftware.com
>>> email sc...@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).

 I'm a little frantic.

 --
 Jacqueline Landman Gay | jac...@hyperactivesw.com
 HyperActive Software   | http://www.hyperactivesw.com

 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>> --
>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>> HyperActive Software   | http://www.hyperactivesw.com
>>
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your 
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-02 Thread J. Landman Gay via use-livecode

I was considering that when Trevor contacted me and suggested his DataView 
(he posted about it today) and it's the same idea. I'm going to look into 
that, it sounds promising.


I really appreciate the responses here, you guys are awesome.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On May 2, 2020 6:38:05 PM scott--- via use-livecode 
 wrote:


What about having two fields with a small amount of overlapping (same) text 
and as the first field reaches the end of its scroll, the second field 
could be displayed and begin its scroll…

—Scott


On May 2, 2020, at 10:25 AM, J. Landman Gay via use-livecode 
 wrote:


I think the solution has to be in the engine. I'm in trouble.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On May 2, 2020 2:27:53 AM scott--- via use-livecode 
 wrote:


I’ve run into that a few times but not recently. I couldn’t find anywhere 
that I had worked around it. All I can imagine trying is

1. Swapping text in and out at some point (possibly just one giant stutter) or
2. Changing the size of the text that is not visible during the scroll… 
though (the more I think about that one the more it seems like it would 
make the scroll wacky in other ways)  Neither seems super-promising but 
that’s all I can think of at the moment. If you find a solution, I would 
love to know what it is.

—
Scott


On May 1, 2020, at 10:24 PM, J. Landman Gay via use-livecode 
 wrote:


Yes, that seems to be the problem. I have a long text field that exceeds 
the maximum. There's an enclosing group to be compatible with 
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, 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 can't break up the text, 
it has to be all one block. I have tried setting the group to container 
layermode without success.


If you're wondering why the text exceeds the maximum, this is for a mobile 
app and there is not only a lot of heavy formatting with large headings and 
spaceBelow, but the text size is largish so that it is readable on a tiny 
phone. That makes the pixel count pretty high.


I only have a very short time left to solve this.

On 5/1/20 4:45 PM, scott--- via use-livecode wrote:

Are you exceeding the maximum vertical scroll?
(I haven’t run into this recently but I believe at one point the vScroll of 
groups was limited at the engine level to 32780)

Scott Morrow
Elementary Software
(Now with 20% less chalk dust!)
web   https://elementarysoftware.com/
email sc...@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).


I'm a little frantic.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-02 Thread scott--- via use-livecode

What about having two fields with a small amount of overlapping (same) text and 
as the first field reaches the end of its scroll, the second field could be 
displayed and begin its scroll… 
—Scott


> On May 2, 2020, at 10:25 AM, J. Landman Gay via use-livecode 
>  wrote:
> 
> I think the solution has to be in the engine. I'm in trouble.
> 
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On May 2, 2020 2:27:53 AM scott--- via use-livecode 
>  wrote:
> 
>> I’ve run into that a few times but not recently. I couldn’t find anywhere 
>> that I had worked around it. All I can imagine trying is
>> 1. Swapping text in and out at some point (possibly just one giant stutter) 
>> or
>> 2. Changing the size of the text that is not visible during the scroll… 
>> though (the more I think about that one the more it seems like it would make 
>> the scroll wacky in other ways)  Neither seems super-promising but that’s 
>> all I can think of at the moment. If you find a solution, I would love to 
>> know what it is.
>> —
>> Scott
>> 
>> 
>>> On May 1, 2020, at 10:24 PM, J. Landman Gay via use-livecode 
>>>  wrote:
>>> 
>>> Yes, that seems to be the problem. I have a long text field that exceeds 
>>> the maximum. There's an enclosing group to be compatible with 
>>> 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, 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 can't break up the text, 
>>> it has to be all one block. I have tried setting the group to container 
>>> layermode without success.
>>> 
>>> If you're wondering why the text exceeds the maximum, this is for a mobile 
>>> app and there is not only a lot of heavy formatting with large headings and 
>>> spaceBelow, but the text size is largish so that it is readable on a tiny 
>>> phone. That makes the pixel count pretty high.
>>> 
>>> I only have a very short time left to solve this.
>>> 
>>> On 5/1/20 4:45 PM, scott--- via use-livecode wrote:
 Are you exceeding the maximum vertical scroll?
 (I haven’t run into this recently but I believe at one point the vScroll 
 of groups was limited at the engine level to 32780)
 Scott Morrow
 Elementary Software
 (Now with 20% less chalk dust!)
 web   https://elementarysoftware.com/
 email sc...@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).
> 
> I'm a little frantic.
> 
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-02 Thread J. Landman Gay via use-livecode


I think the solution has to be in the engine. I'm in trouble.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On May 2, 2020 2:27:53 AM scott--- via use-livecode 
 wrote:


I’ve run into that a few times but not recently. I couldn’t find anywhere 
that I had worked around it. All I can imagine trying is

1. Swapping text in and out at some point (possibly just one giant stutter) or
2. Changing the size of the text that is not visible during the scroll… 
though (the more I think about that one the more it seems like it would 
make the scroll wacky in other ways)  Neither seems super-promising but 
that’s all I can think of at the moment. If you find a solution, I would 
love to know what it is.

—
Scott


On May 1, 2020, at 10:24 PM, J. Landman Gay via use-livecode 
 wrote:


Yes, that seems to be the problem. I have a long text field that exceeds 
the maximum. There's an enclosing group to be compatible with 
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, 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 can't break up the text, 
it has to be all one block. I have tried setting the group to container 
layermode without success.


If you're wondering why the text exceeds the maximum, this is for a mobile 
app and there is not only a lot of heavy formatting with large headings and 
spaceBelow, but the text size is largish so that it is readable on a tiny 
phone. That makes the pixel count pretty high.


I only have a very short time left to solve this.

On 5/1/20 4:45 PM, scott--- via use-livecode wrote:

Are you exceeding the maximum vertical scroll?
(I haven’t run into this recently but I believe at one point the vScroll of 
groups was limited at the engine level to 32780)

Scott Morrow
Elementary Software
(Now with 20% less chalk dust!)
web   https://elementarysoftware.com/
email sc...@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).


I'm a little frantic.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-02 Thread scott--- via use-livecode

I’ve run into that a few times but not recently. I couldn’t find anywhere that 
I had worked around it. All I can imagine trying is 
1. Swapping text in and out at some point (possibly just one giant stutter) or 
2. Changing the size of the text that is not visible during the scroll… though 
(the more I think about that one the more it seems like it would make the 
scroll wacky in other ways)  Neither seems super-promising but that’s all I can 
think of at the moment. If you find a solution, I would love to know what it is.
—
Scott


> On May 1, 2020, at 10:24 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> Yes, that seems to be the problem. I have a long text field that exceeds the 
> maximum. There's an enclosing group to be compatible with 
> 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, 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 can't break up the text, it has 
> to be all one block. I have tried setting the group to container layermode 
> without success.
> 
> If you're wondering why the text exceeds the maximum, this is for a mobile 
> app and there is not only a lot of heavy formatting with large headings and 
> spaceBelow, but the text size is largish so that it is readable on a tiny 
> phone. That makes the pixel count pretty high.
> 
> I only have a very short time left to solve this.
> 
> On 5/1/20 4:45 PM, scott--- via use-livecode wrote:
>> Are you exceeding the maximum vertical scroll?
>> (I haven’t run into this recently but I believe at one point the vScroll of 
>> groups was limited at the engine level to 32780)
>> Scott Morrow
>> Elementary Software
>> (Now with 20% less chalk dust!)
>> web   https://elementarysoftware.com/
>> email sc...@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).
>>> 
>>> I'm a little frantic.
>>> 
>>> -- 
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software   | http://www.hyperactivesw.com
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

2020-05-01 Thread J. Landman Gay via use-livecode

Yes, that seems to be the problem. I have a long text field that exceeds the maximum. There's
an enclosing group to be compatible with 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, 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 can't break up the text, it has to be all one block. I have tried setting the group
to container layermode without success.

If you're wondering why the text exceeds the maximum, this is for a mobile app and there is not
only a lot of heavy formatting with large headings and spaceBelow, but the text size is largish
so that it is readable on a tiny phone. That makes the pixel count pretty high.

I only have a very short time left to solve this.

On 5/1/20 4:45 PM, scott--- via use-livecode wrote:

Are you exceeding the maximum vertical scroll?
(I haven’t run into this recently but I believe at one point the vScroll of
groups was limited at the engine level to 32780)

Scott Morrow

Elementary Software
(Now with 20% less chalk dust!)
web https://elementarysoftware.com/
email sc...@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).

I'm a little frantic.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com

Re: FormattedHeight

2020-05-01 Thread scott--- via use-livecode

Are you exceeding the maximum vertical scroll?
(I haven’t run into this recently but I believe at one point the vScroll of 
groups was limited at the engine level to 32780)

Scott Morrow

Elementary Software
(Now with 20% less chalk dust!)
web   https://elementarysoftware.com/
email sc...@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).
> 
> I'm a little frantic.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode









___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: FormattedHeight

2020-05-01 Thread Ralph DiMola via use-livecode

Did a quick tests on both 9.0.5 and 9.6dp4 it seems to work the same. What
do you see wrong?

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay 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
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight of a field and its contents

2018-02-05 Thread Bob Sneidar via use-livecode

Fonts have natural margins that vary widely. A decorative or cursive font may 
have ascenders and descenders much higher and lower than a book typeface. That 
means the leading between the lines needs to be larger. I use display font for 
the labels for my forms, called Verdana has an automatic 16 point margin at 14 
point font size, even though there is nothing about the font itself requiring 
it! It's just how the font is done. 

Bob S


> On Feb 3, 2018, at 09:12 , Ralph DiMola via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> David,
> 
> Nice I've been wrestling with this. I am going to see how your 
> observations translate into mobile. I'm going to apply your of findings to my 
> app and see if I get better results than I get now. There have been a few 
> threads in the past few years addressing vertically centering text in a 
> field. None of them seem to address all font size cases. This 6px thingy 
> might explain a lot! 
> 
> Thanks again for all your work.
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
> 
> -Original Message-
> 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
> 
> Thanks for the responses on this.  I used Bernd’s tool and did some more 
> tests, and found some things that may be helpful to others.
> 
> While the left and right margins of a field are meant literally (a 5 pixel 
> left margin leaves 5 white pixels to the left of the text), the top margin is 
> more complicated, no doubt owing to the variety of textHeights that need to 
> be accommodated.  For example, a margin of "0" will often clip the top of the 
> text--as if "0" meant a "negative margin".
> 
> 6 seems to be a magic default value for a field's top margin, which 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 
> horizontal scrollbar changes this).
> 
> Thus--what I wondered about in my original post--with a margin less than 6 
> the formattedHeight of the field is less than the formattedHeight of the 
> content; the content is in effect clipped.  At smaller textHeights this will 
> be visible, while at larger textHeights only white space above the characters 
> is clipped.
> 
> I was trying to answer two questions, and I think I'm pretty close.
> 
> 1. How do I make sure that the field's contents are all visible if I set the 
> field's height to the formattedHeight?  Answer: Set the top and bottom 
> margins to 6. For the left and right margins, even 1 pixel should be enough 
> to keep everything visible.
> 
> 2. What margins will provide a symmetrical look for a text box?
> A top margin of 6 doesn’t look like a 6 pixel margin; how it looks depends on 
> the textHeight.  I estimate that its apparent height is one fourth of the 
> effective textHeight, and I use this to size the other margins in the 
> “tightMargins” handler below.
> While the top margin of 6 looks good with horizontal gridlines, without them 
> (and especially if you show a text baseline) it looks too small compared to 
> the space between subsequent lines.  To match that larger space, in effect 
> doubling the apparent top margin, add one third of the effective textHeight.  
> See “niceMargins” handler below.
> 
> Example of usage:
> set the margins of fld 1 to the niceMargins of fld 1 set the height of fld 1 
> to the formattedHeight of fld 1
> 
> getProp niceMargins
>   put the effective textHeight of the target into t
>   put round(t*7/12) into m1
>   put round(t/3) into m2
>   return m1,6+m2,m1,m1
> end niceMargins
> 
> getProp tightMargins
>   put round(.25*the effective textHeight of the target) into m
>   return m,6,m,max(6,m)
> end tightMargins
> 
> Improvements to these are welcomed.
> 
> David Epstein
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: FormattedHeight of a field and its contents

2018-02-03 Thread Ralph DiMola via use-livecode

David,

Nice I've been wrestling with this. I am going to see how your observations 
translate into mobile. I'm going to apply your of findings to my app and see if 
I get better results than I get now. There have been a few threads in the past 
few years addressing vertically centering text in a field. None of them seem to 
address all font size cases. This 6px thingy might explain a lot! 

Thanks again for all your work.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
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

Thanks for the responses on this.  I used Bernd’s tool and did some more tests, 
and found some things that may be helpful to others.

While the left and right margins of a field are meant literally (a 5 pixel left 
margin leaves 5 white pixels to the left of the text), the top margin is more 
complicated, no doubt owing to the variety of textHeights that need to be 
accommodated.  For example, a margin of "0" will often clip the top of the 
text--as if "0" meant a "negative margin".

6 seems to be a magic default value for a field's top margin, which 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 horizontal scrollbar 
changes this).

Thus--what I wondered about in my original post--with a margin less than 6 the 
formattedHeight of the field is less than the formattedHeight of the content; 
the content is in effect clipped.  At smaller textHeights this will be visible, 
while at larger textHeights only white space above the characters is clipped.

I was trying to answer two questions, and I think I'm pretty close.

1. How do I make sure that the field's contents are all visible if I set the 
field's height to the formattedHeight?  Answer: Set the top and bottom margins 
to 6. For the left and right margins, even 1 pixel should be enough to keep 
everything visible.

2. What margins will provide a symmetrical look for a text box?
A top margin of 6 doesn’t look like a 6 pixel margin; how it looks depends on 
the textHeight.  I estimate that its apparent height is one fourth of the 
effective textHeight, and I use this to size the other margins in the 
“tightMargins” handler below.
While the top margin of 6 looks good with horizontal gridlines, without them 
(and especially if you show a text baseline) it looks too small compared to the 
space between subsequent lines.  To match that larger space, in effect doubling 
the apparent top margin, add one third of the effective textHeight.  See 
“niceMargins” handler below.

Example of usage:
set the margins of fld 1 to the niceMargins of fld 1 set the height of fld 1 to 
the formattedHeight of fld 1

getProp niceMargins
   put the effective textHeight of the target into t
   put round(t*7/12) into m1
   put round(t/3) into m2
   return m1,6+m2,m1,m1
end niceMargins

getProp tightMargins
   put round(.25*the effective textHeight of the target) into m
   return m,6,m,max(6,m)
end tightMargins

Improvements to these are welcomed.

David Epstein


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight of a field and its contents

2018-02-02 Thread David Epstein via use-livecode

Thanks for the responses on this.  I used Bernd’s tool and did some more tests, 
and found some things that may be helpful to others.

While the left and right margins of a field are meant literally (a 5 pixel left 
margin leaves 5 white pixels to the left of the text), the top margin is more 
complicated, no doubt owing to the variety of textHeights that need to be 
accommodated.  For example, a margin of "0" will often clip the top of the 
text--as if "0" meant a "negative margin".

6 seems to be a magic default value for a field's top margin, which 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 horizontal scrollbar 
changes this).

Thus--what I wondered about in my original post--with a margin less than 6 the 
formattedHeight of the field is less than the formattedHeight of the content; 
the content is in effect clipped.  At smaller textHeights this will be visible, 
while at larger textHeights only white space above the characters is clipped.

I was trying to answer two questions, and I think I'm pretty close.

1. How do I make sure that the field's contents are all visible if I set the 
field's height to the formattedHeight?  Answer: Set the top and bottom margins 
to 6. For the left and right margins, even 1 pixel should be enough to keep 
everything visible.

2. What margins will provide a symmetrical look for a text box?
A top margin of 6 doesn’t look like a 6 pixel margin; how it looks depends on 
the textHeight.  I estimate that its apparent height is one fourth of the 
effective textHeight, and I use this to size the other margins in the 
“tightMargins” handler below.
While the top margin of 6 looks good with horizontal gridlines, without them 
(and especially if you show a text baseline) it looks too small compared to the 
space between subsequent lines.  To match that larger space, in effect doubling 
the apparent top margin, add one third of the effective textHeight.  See 
“niceMargins” handler below.

Example of usage:
set the margins of fld 1 to the niceMargins of fld 1
set the height of fld 1 to the formattedHeight of fld 1

getProp niceMargins
   put the effective textHeight of the target into t
   put round(t*7/12) into m1
   put round(t/3) into m2
   return m1,6+m2,m1,m1
end niceMargins

getProp tightMargins
   put round(.25*the effective textHeight of the target) into m
   return m,6,m,max(6,m)
end tightMargins

Improvements to these are welcomed.

David Epstein


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight of a field and its contents

2018-02-01 Thread Paul Dupuis via use-livecode

What version of LiveCode on what platform are you trying this on?

There have been a number of bugs related to object geometry
calculations, including fields, over the years, found and fixed in
various releases of LC. Some were platform and version of OS specific.

On 1/31/2018 8:31 PM, David 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 margins”, while the 
> formattedHeight of a chunk is calculated “disregarding margins.”
>
> That does not seem consistent with these results for a field whose textSize 
> is 16 and whose margin is 4:
>
> the formattedHeight of line 1 of fld 1 19
> the formattedHeight of line 1 to 2 of fld 1  38
> the formattedHeight of fld 1   15  if there’s one 
> line of text
> the formattedHeight of fld 1   34  if there are 
> two lines of text.
>
> Even though there are top and bottom margins of 4, the field’s 
> formattedHeight is smaller, rather than larger, than the formattedHeight of 
> its contents.
>
> A perhaps related question:  Why does a field margin of zero clip the visible 
> text at the top and left?
>
> Many thanks.
>
> David Epstein
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight of a field and its contents

2018-02-01 Thread Bob Sneidar via use-livecode

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 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 not seem consistent with these results for a field whose textSize 
> is 16 and whose margin is 4:
> 
> the formattedHeight of line 1 of fld 1 19
> the formattedHeight of line 1 to 2 of fld 1  38
> the formattedHeight of fld 1   15  if there’s one 
> line of text
> the formattedHeight of fld 1   34  if there are 
> two lines of text.
> 
> Even though there are top and bottom margins of 4, the field’s 
> formattedHeight is smaller, rather than larger, than the formattedHeight of 
> its contents.
> 
> A perhaps related question:  Why does a field margin of zero clip the visible 
> text at the top and left?
> 
> Many thanks.
> 
> David Epstein

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight of a field and its contents

2018-02-01 Thread BNig via use-livecode

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-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight Limit!

2012-08-06 Thread Scott Rossi

Seems like you can either 1) split the text across two fields, or 2) show
only the lines that will fit comfortably within the field's rect at any one
time

Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design




Recently, Rick Harrison wrote:

 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 want to use my larger font size,
 and I don't want to cut down on the number
 of lines in my field.  Any work arounds for this?
 
 Thanks in advance,
 
 Rick
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight Limit!

2012-08-06 Thread Dan Friedman

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.

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
 beyond a limit of 32,768 and causes
 an unreported error in the iOS Simulator.
 
 I really want to use my larger font size,
 and I don't want to cut down on the number
 of lines in my field.  Any work arounds for this?
 
 Thanks in advance,
 
 Rick

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight Limit!

2012-08-06 Thread Rick Harrison

Hi Dan,

An interesting idea, however the problem is with the following line of code,
which takes place in the preOpenCard script.

  set the height of field ViewingField5 of this card to tHeight5

(When tHeight5  32768 the above line of code fails in the iOS Simulator
and does not complete any more script statements after that line with no
error message being generated.  At this point nothing is being executed
on the group.  It is a variable going beyond the limit here.  Is there any way
to make the variable bigger like a double precision integer or some such thing?)

Suggestions?

Thanks,

Rick

On Aug 6, 2012, at 5:41 PM, Dan Friedman wrote:

 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.
 
 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
 beyond a limit of 32,768 and causes
 an unreported error in the iOS Simulator.
 
 I really want to use my larger font size,
 and I don't want to cut down on the number
 of lines in my field.  Any work arounds for this?
 
 Thanks in advance,
 
 Rick
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode

__
Rick Harrison

You can buy my $10 music album Funny Time Machine digital CD on the iTunes 
Store Now!

To visit the iTunes Store now to listen to samples of my CD please click on the
following link.  (Please note you must have iTunes installed on your computer 
for this link to work.)  

http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewAlbum?playListId=213668290


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight Limit!

2012-08-06 Thread Bob Sneidar

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-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight Limit!

2012-08-06 Thread Rick Harrison

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(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-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight Limit!

2012-08-06 Thread Thomas McGrath III

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:47 PM, Rick Harrison harri...@all-auctions.com wrote:

 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(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-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight Limit!

2012-08-06 Thread Dan Friedman

Rick,

Don't change the height of the field to match it's contents, set it to the 
display size.  For example, if your field is to *display* on the entire screen, 
then do this:

set the rect of fld ViewingField5 to the rect of this card

Then, fill it with the data.  Next, set the iOS scroller's contentRect to (the 
formattedRect of field ViewingField5).  Finally, in your scrollerDidScroll 
message, don't set the scroll of the group containing field ViewingField5, 
simply set the scroll of field ViewingField5.  Make sense?

Works fine for me.

-Dan


 Hi Dan,
 
 An interesting idea, however the problem is with the following line of code,
 which takes place in the preOpenCard script.
 
  set the height of field ViewingField5 of this card to tHeight5
 
 (When tHeight5  32768 the above line of code fails in the iOS Simulator
 and does not complete any more script statements after that line with no
 error message being generated.  At this point nothing is being executed
 on the group.  It is a variable going beyond the limit here.  Is there any way
 to make the variable bigger like a double precision integer or some such 
 thing?)
 
 Suggestions?
 
 Thanks,
 
 Rick
 
 On Aug 6, 2012, at 5:41 PM, Dan Friedman wrote:
 
 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.
 
 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
 beyond a limit of 32,768 and causes
 an unreported error in the iOS Simulator.
 
 I really want to use my larger font size,
 and I don't want to cut down on the number
 of lines in my field.  Any work arounds for this?
 
 Thanks in advance,
 
 Rick

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: formattedHeight and scrollbars

2012-02-01 Thread Howard Bornstein

Hi,

I was having some issues with formattedTextHeight and came across this
post. I looked at your revlet and it suggested some things that solved my
problem. Thank you for that!

I wondered if you would be willing to send me the LC stack you made this
revlet from. It would be very useful to have as a reference when I run into
these kinds of problems again (and when I'm not online).

Thanks in advance.

--
Regards,

Howard Bornstein
---
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 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 to the
formattedHeight if I remember correctly.

Kind regards

Bernd
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/formattedHeight-and-scrollbars-tp3309720p3309965.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: formattedHeight and scrollbars

2012-02-01 Thread Howard Bornstein

oops, sorry, that was meant to be a private email.

On Wed, Feb 1, 2012 at 1:54 PM, Howard Bornstein bornst...@designeq.comwrote:

Hi,

I was having some issues with formattedTextHeight and came across this
post. I looked at your revlet and it suggested some things that solved my
problem. Thank you for that!

Thanks in advance.

--
Regards,

Howard Bornstein
---
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/

Kind regards

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

--
Regards,

Howard Bornstein
---
www.designeq.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: formattedheight and formattedwidth

2011-06-27 Thread Richard Gaskin


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 stack,
not the current card.


This thread confuses me, since the height and width properties of a card 
object cannot be set at all.


A card is merely a container for controls inside the stack, allowing 
multiple sets of controls within a given window.  But the card always 
fills the stack, so changing the size of the stack will change the size 
of the card, but the size of the card itself cannot be set 
independently. Indeed, if it could what would happen to the area beyond 
the edges of a card which is smaller than the window displaying it?


AFAIK, there's only one exception to the general rule that the card size 
will always be the same as the stack size:  if the stack has a menubar 
defined, its editMenus property is false (the default), and it's 
currently running under OS X.


Since OS X has a global menu bar, the stack's menubar is scrolled out of 
view and the size of the stack is automatically cropped by the height of 
the menubar group.


In that case, the height of the card will be the stack height + the 
height of the menubar group, and the card width will remain the same as 
the stack's width.


Aside from that one set of circumstances on OS X, the card size should 
always reflect the stack size, and even on OS X with a menubar the stack 
size still governs the card size, the only difference being the height 
of the menubar group.


So if you want to change the size of the window, just change the size of 
the stack.


If you don't want to change the size of the window, what is the goal of 
attempting to change the card size?


--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.com/blog.irv

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: formattedheight and formattedwidth

2011-06-27 Thread Pete

I am changing the stack size.  Each card in the stack in question needs to
have a different height and width dimension in order for all its controls to
be visible and, as you rightly point out, that has to be done by setting the
height and width properties of the stack, not the card.

I had initially inserted lines of code in the preOpenCard handler for each
individual card that set the height and width of the stack to specific
numbers.  But if I changed the design of the card or added a new card, I had
to change 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
do it, suitably adjusted to account for margins on each side of the card.
 The code I now use is:

set the height of this stack to the formattedheight of this card + 20
set the width of this stack to he formattedwidth of this card + 20

That works for any card in the stack as long as I make sure that the top let
control is positioned 10 pixels from the top and 10 pixels from the left
edge.

Hope that clears up the confusion.

Pete
Molly's Revenge http://www.mollysrevenge.com




On Mon, Jun 27, 2011 at 7:27 AM, Richard Gaskin
ambassa...@fourthworld.comwrote:

 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 stack,
 not the current card.


 This thread confuses me, since the height and width properties of a card
 object cannot be set at all.

 A card is merely a container for controls inside the stack, allowing
 multiple sets of controls within a given window.  But the card always fills
 the stack, so changing the size of the stack will change the size of the
 card, but the size of the card itself cannot be set independently. Indeed,
 if it could what would happen to the area beyond the edges of a card which
 is smaller than the window displaying it?

 AFAIK, there's only one exception to the general rule that the card size
 will always be the same as the stack size:  if the stack has a menubar
 defined, its editMenus property is false (the default), and it's currently
 running under OS X.

 Since OS X has a global menu bar, the stack's menubar is scrolled out of
 view and the size of the stack is automatically cropped by the height of the
 menubar group.

 In that case, the height of the card will be the stack height + the height
 of the menubar group, and the card width will remain the same as the stack's
 width.

 Aside from that one set of circumstances on OS X, the card size should
 always reflect the stack size, and even on OS X with a menubar the stack
 size still governs the card size, the only difference being the height of
 the menubar group.

 So if you want to change the size of the window, just change the size of
 the stack.

 If you don't want to change the size of the window, what is the goal of
 attempting to change the card size?

 --
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: 
 http://LiveCodejournal.com/**blog.irvhttp://LiveCodejournal.com/blog.irv


 __**_
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/**mailman/listinfo/use-livecodehttp://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: formattedheight and formattedwidth

2011-06-27 Thread Bob Sneidar

Another way to do this is to have an object like a graphic on each card the
size you want the card to be. You could put a handler in the object so that
right clicking on it popped a menu, allowing you to select some pre-set sizes
for the card, or make a custom size. Once selected, the graphic object could be
sized appropriately, and then you could set the stack size to the formatted
height and formatted width. The object size itself would be the remembering.

If you already have a graphic object for your background pattern all the
better. To prevent end users of your app (if there will be some) from doing the
same thing, make a stack script that sets a property for devmode or something,
and set it to false before compiling your stack. Check the value of the
property before allowing the right-click to pop the menu.

I think that is how I would do it.

Bob

On Jun 27, 2011, at 9:15 AM, Pete wrote:

I am changing the stack size. Each card in the stack in question needs to
have a different height and width dimension in order for all its controls to
be visible and, as you rightly point out, that has to be done by setting the
height and width properties of the stack, not the card.

I had initially inserted lines of code in the preOpenCard handler for each
individual card that set the height and width of the stack to specific
numbers. But if I changed the design of the card or added a new card, I had
to change 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
do it, suitably adjusted to account for margins on each side of the card.
The code I now use is:

set the height of this stack to the formattedheight of this card + 20
set the width of this stack to he formattedwidth of this card + 20

That works for any card in the stack as long as I make sure that the top let
control is positioned 10 pixels from the top and 10 pixels from the left
edge.

Hope that clears up the confusion.

Pete
Molly's Revenge http://www.mollysrevenge.com

On Mon, Jun 27, 2011 at 7:27 AM, Richard Gaskin
ambassa...@fourthworld.comwrote:

Pete wrote:

This thread confuses me, since the height and width properties of a card
object cannot be set at all.

A card is merely a container for controls inside the stack, allowing
multiple sets of controls within a given window. But the card always fills
the stack, so changing the size of the stack will change the size of the
card, but the size of the card itself cannot be set independently. Indeed,
if it could what would happen to the area beyond the edges of a card which
is smaller than the window displaying it?

AFAIK, there's only one exception to the general rule that the card size
will always be the same as the stack size: if the stack has a menubar
defined, its editMenus property is false (the default), and it's currently
running under OS X.

Since OS X has a global menu bar, the stack's menubar is scrolled out of
view and the size of the stack is automatically cropped by the height of the
menubar group.

In that case, the height of the card will be the stack height + the height
of the menubar group, and the card width will remain the same as the stack's
width.

Aside from that one set of circumstances on OS X, the card size should
always reflect the stack size, and even on OS X with a menubar the stack
size still governs the card size, the only difference being the height of
the menubar group.

So if you want to change the size of the window, just change the size of
the stack.

If you don't want to change the size of the window, what is the goal of
attempting to change the card size?

--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog:
http://LiveCodejournal.com/**blog.irvhttp://LiveCodejournal.com/blog.irv

__**_
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/**mailman/listinfo/use-livecodehttp://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:

Re: formattedheight and formattedwidth

2011-06-26 Thread Pete

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 the height of this card
set the width of this stack to the width of this card

Is that what you meant? That sometimes works and sometimes isn't close.

Pete
Molly's Revenge http://www.mollysrevenge.com

On Sat, Jun 25, 2011 at 7:04 PM, J. Landman Gay jac...@hyperactivesw.comwrote:

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 this card

The height and width end up several pixels short of what they need to be.
Adding 10 to the fomattedheight and 20 to the formattedwidth makes things
about right, but

Use the height and width, not the formattedHeight and formattedWidth. The
formatted measurements only include the smallest area that encompasses all
the visible objects objects. If the card objects don't touch all four sides,
the formatted measurements will be smaller than the card measurements.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com

Re: formattedheight and formattedwidth

2011-06-26 Thread J. Landman Gay


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 accurate to me. The formatted measurement is the amount of 
space occupied by all visible objects on the card. It is calculated from 
the smallest rectangle that will enclose all of them. It does not 
include any empty borders around that area.



I tried this:


set the height of this stack to the height of this card
set the width of this stack to the width of this card


Is  that what you meant? That sometimes works and sometimes isn't close.


Yes, that's what I meant, assuming you want to set the window to same 
size as the card. If you are on OS X and you have a menu bar set, the 
top of the card will be scrolled out of view, so the height of the card 
will actually be taller than what you see before you change the size. If 
you are getting extra space at the bottom of the window then that's 
probably why. If you are on Windows then the card and window height 
should match up without any differences.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: formattedheight and formattedwidth

2011-06-26 Thread Pete

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 stack,
not the current card. I've tried this in preOpenStack and preOpenCard so
maybe this card in the prewOpen handlers is still set to the last card
opened since this one hasn't been opened yet?

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.

Pete
Molly's Revenge http://www.mollysrevenge.com

On Sun, Jun 26, 2011 at 3:55 PM, J. Landman Gay jac...@hyperactivesw.comwrote:

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 accurate to me. The formatted measurement is the amount of space
occupied by all visible objects on the card. It is calculated from the
smallest rectangle that will enclose all of them. It does not include any
empty borders around that area.

I tried this:

set the height of this stack to the height of this card
set the width of this stack to the width of this card

Is that what you meant? That sometimes works and sometimes isn't close.

Yes, that's what I meant, assuming you want to set the window to same size
as the card. If you are on OS X and you have a menu bar set, the top of the
card will be scrolled out of view, so the height of the card will actually
be taller than what you see before you change the size. If you are getting
extra space at the bottom of the window then that's probably why. If you are
on Windows then the card and window height should match up without any
differences.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com

Re: formattedheight and formattedwidth

2011-06-26 Thread Robert Brenstein


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, then you could save the desired width and 
height of each card in custom properties and resize each card in 
preopencard.


Robert

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: formattedheight and formattedwidth

2011-06-26 Thread Pete

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 and formatted width during preOpenCard. That seems to
work just fine.

Pete
Molly's Revenge http://www.mollysrevenge.com




On Sun, Jun 26, 2011 at 6:12 PM, Robert Brenstein r...@robelko.com wrote:

 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, then you could save the desired width and height of each card in
 custom properties and resize each card in preopencard.

 Robert


 __**_
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/**mailman/listinfo/use-livecodehttp://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: formattedheight and formattedwidth

2011-06-25 Thread J. Landman Gay


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 this card

The height and width end up several pixels short of what they need to be.
  Adding 10 to the fomattedheight and 20 to the formattedwidth makes things
about right, but


Use the height and width, not the formattedHeight and formattedWidth. 
The formatted measurements only include the smallest area that 
encompasses all the visible objects objects. If the card objects don't 
touch all four sides, the formatted measurements will be smaller than 
the card measurements.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: formattedHeight and scrollbars

2011-03-05 Thread Claus Dreischer

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 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 to *94*.
 
 The scrollbar is counted twice.
 
 I would have expected the new formattedHeight to jump to 84.
 
 Can someone please explain the logic behind this (when it's intended)?
 
 
 Regards,
   Claus.
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: formattedHeight and scrollbars

2011-02-17 Thread Claus Dreischer

Hi,

Am 17.02.11 01:02, schrieb dunb...@aol.com:
 A fun revlet.

Indeed!


 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.

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 do both.
(Well at least if you are no banker or politician or something like hat
:- )

Example:
- Start Bernds Revlet
- set textHeight to 11
- set textSize to 1
- gives you formattedHeight of 70
- The height of the field is 78 (i checked with Bernd)
- The difference of 8 pixel (78-70) is the free space below the text
- Now set the scrollbarWidth to 8
- enable the hScrollbar
- The 8 pixel scrollbar takes the place of that free space
- *BUT* the formattedHeight is now 86,
  which implies that you need additional 8 pixel
  to display its full contents without scrolling (Dictionary).

  This is just not true.

the height needed by an object to display its full contents without
scrolling (Dictionary) is 80, Bernds Revlet demonstrates it clearly.

Or, where in the above did i go wrong?


Regards,
Claus.


[...]

 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. Before 4.5 on a Mac the focusborder also added to the
 formattedHeight if I remember correctly.
 
 Kind regards
 
 Bernd

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

43 matches

Mail list logo