Re: formattedHeight formattedWidth on android

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

Re: FormattedHeight

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

Re: FormattedHeight

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

Re: FormattedHeight

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

Re: FormattedHeight

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

Re: FormattedHeight

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

Re: FormattedHeight

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

Re: FormattedHeight

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

Re: FormattedHeight

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,

Re: FormattedHeight

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

Re: FormattedHeight

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

Re: FormattedHeight

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

Re: FormattedHeight

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

Re: FormattedHeight

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

Re: FormattedHeight

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

Re: FormattedHeight

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

RE: FormattedHeight

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

Re: FormattedHeight of a field and its contents

> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf > Of David Epstein via use-livecode > Sent: Friday, February 02, 2018 9:38 PM > To: use-livecode@lists.runrev.com > Cc: David Epstein > Subject: Re: FormattedHeight of a field and its contents > > Th

RE: FormattedHeight of a field and its contents

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

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

Re: FormattedHeight of a field and its contents

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

Re: FormattedHeight of a field and its contents

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

Re: FormattedHeight of a field and its contents

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:

Re: FormattedHeight Limit!

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

Re: FormattedHeight Limit!

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.

Re: FormattedHeight Limit!

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

Re: FormattedHeight Limit!

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

Re: FormattedHeight Limit!

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

Re: FormattedHeight Limit!

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

Re: FormattedHeight Limit!

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

Re: formattedHeight and scrollbars

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

Re: formattedHeight and scrollbars

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.

Re: formattedheight and formattedwidth

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

Re: formattedheight and formattedwidth

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

Re: formattedheight and formattedwidth

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

Re: formattedheight and formattedwidth

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

Re: formattedheight and formattedwidth

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

Re: formattedheight and formattedwidth

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

Re: formattedheight and formattedwidth

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,

Re: formattedheight and formattedwidth

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

Re: formattedheight and formattedwidth

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

Re: formattedHeight and scrollbars

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

Re: formattedHeight and scrollbars

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