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 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
formattedHeight formattedWidth on android
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
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 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
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
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
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
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
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
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
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.hypera
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 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 preferenc
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 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
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
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
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
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
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 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
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
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
Re: FormattedHeight of a field and its contents
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
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
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
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
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 > <use-livecode@lists.runrev.com> 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
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
FormattedHeight of a field and its contents
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: margins ignored in formattedHeight for 8?
On Thu, Nov 10, 2016 at 1:39 PM, J. Landman Gay <jac...@hyperactivesw.com> wrote: > Interesting...I'm working with formattedheight today too. I have a field > placed under an image where it can't be seen. It slides down sometimes and > moves everything below it down to accomodate. When I get the > formattedheight of the group the controls are in, it returns the same > number regardless of whether the field is under the image or below it. I just filed as *Bug 18832* <http://quality.livecode.com/show_bug.cgi?id=18832> - margins not included in formattedHeight on field (edit <http://quality.livecode.com/post_bug.cgi#>) -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: margins ignored in formattedHeight for 8?
Interesting...I'm working with formattedheight today too. I have a field placed under an image where it can't be seen. It slides down sometimes and moves everything below it down to accomodate. When I get the formattedheight of the group the controls are in, it returns the same number regardless of whether the field is under the image or below it. Something's odd. LC 8.1.1. On 11/10/16 3:16 PM, Dr. Hawkins wrote: Is 8 ignoring margins in calculating formattedHeight? Placing a single line of text into a field, which is Helvitica Bold size 9, and margins of 0,6,0,0, it manages to return a formattedHeight of 7 when checking . . . uhh . . . . Am I missing something here? This worked for years in 5/7 for years; now I am having to add the topMargin explicitly, with timers (if the seconds > something then breakpoint) to remember to take them back out. -- 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
margins ignored in formattedHeight for 8?
Is 8 ignoring margins in calculating formattedHeight? Placing a single line of text into a field, which is Helvitica Bold size 9, and margins of 0,6,0,0, it manages to return a formattedHeight of 7 when checking . . . uhh . . . . Am I missing something here? This worked for years in 5/7 for years; now I am having to add the topMargin explicitly, with timers (if the seconds > something then breakpoint) to remember to take them back out. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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
formattedHeight of a button
There seems to be a problem with the formattedHeight property of a button. I'm assigning an icon to the button and leaving the showName property to true. By doing that, I can make the button high enough so that the button name shows under the icon. The formattedwidth property seems to work fine in that it reflects the width required to include the button label. However, if I check the formattedheight of the button, it is less than its height and if I set its height to the formattedHeight, the top of the icon is chopped off. This seems like a bug to me but thought I would check to see if there is a reason for this. Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.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: height limit (was FormattedHeight Limit!)
Hi Dan, I have several fields on one card so I don't want the field to display on the entire card, as it ruins everything else. I understand you are trying to use that as an example, but other than the display what should I be setting the rect to if not the size of the contents for scrolling? It is the Livecode height variable in pixels that has the limitation of 32,768. Perhaps if you had some example code to share things might make more sense? Your help is greatly appreciated! Rick On Aug 7, 2012, at 12:08 AM, Dan Friedman wrote: 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 ___ 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
FormattedHeight Limit!
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!
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!
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!
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!
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!
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!
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!
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
does Data Grid have a formattedHeight property?
I'm trying to set the height of a data grid based on the formattedHeight property, but as far as I can tell, the formattedHeight of a data grid returns the height. Is this a bug or by design? If by design, is there some other way I can accomplish this? Trevor, are you listening? :-) Thanks, Chris -- Chris Sheffield Read Naturally, Inc. www.readnaturally.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: does Data Grid have a formattedHeight property?
Hi Chris, On Mon, Apr 9, 2012 at 11:55 PM, Chris Sheffield cmsheffi...@me.com wrote: I'm trying to set the height of a data grid based on the formattedHeight property, but as far as I can tell, the formattedHeight of a data grid returns the height. Is this a bug or by design? If by design, is there some other way I can accomplish this? Trevor, are you listening? :-) Have a look to the dgFormattedHeight property in the datagrid API: http://lessons.runrev.com/s/lessons/m/datagrid/l/7344-data-grid-api Best Regards, -- -Zryip TheSlug- wish you the best! 8) http://www.aslugontheroad.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: does Data Grid have a formattedHeight property?
Thank you! I figured it had to be there somewhere. Missed it on my first pass through the docs. On Apr 9, 2012, at 4:34 PM, zryip theSlug wrote: Hi Chris, On Mon, Apr 9, 2012 at 11:55 PM, Chris Sheffield cmsheffi...@me.com wrote: I'm trying to set the height of a data grid based on the formattedHeight property, but as far as I can tell, the formattedHeight of a data grid returns the height. Is this a bug or by design? If by design, is there some other way I can accomplish this? Trevor, are you listening? :-) Have a look to the dgFormattedHeight property in the datagrid API: http://lessons.runrev.com/s/lessons/m/datagrid/l/7344-data-grid-api Best Regards, -- -Zryip TheSlug- wish you the best! 8) http://www.aslugontheroad.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: What is up with FormattedHeight?
Actually, I may be wrong but I seem to recall the script I posted being a variation of something written by Trevor DeVore. Just to keep the credits rolling along... Regards, Scott Rossi Creative Director Tactile Media, UX Design Recently, Howard Bornstein wrote: Wow, thank you Ken and Scott. This was the direction I was planning on pursuing for a solution, but the difference here is that it would have taken me a month, whereas I'm sure Scott knocked this out in his head while brushing his teeth before his morning cup of coffee. Awesome! I appreciate everyone's help with this problem. I also wanted to mention that Bernd Niggemann has been helping me privately and has made some speed-up modifications to Scott's script, which I hope he will post here so others can take advantage of it. ___ 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: What is up with FormattedHeight?
Hi Scott, thanks for posting your script which is as you say based on a script by Trevor DeVore. Since Howard wanted to use this on iOS in a pinch/zoom script I tried to speed up your script. More specifically I scan the alphaData line by line for non-null bytes from top to bottom and from bottom to top. If a non-null byte is found in the alphaData the script gets the row and bails out. Likewise from left to right and right to left the script scans the columns and as soon as a column contains a charToNum 5 it gets the column number and bails out. The advantage is that I don't have to scan every byte of the alphaData which reduces computation time. here is the script: (watch out for linebreaks) --- function bnTextRect pField -- pField expects a long id of a field whose opaque is false -- and returns the bounding rect of the actual letters in the field -- which is different from the formattedRect -- based on a script by Scott Rossi -- http://runtime-revolution.278305.n4.nabble.com/What-is-up-with-FormattedHeight-tt4360344.html#a4372671 lock screen ## CREATE IMAGE WITH ALPHADATA reset the templateImage set lineSize of the templateImage to 0 create image put long id of it into tempImage do export snapshot from pField to tempImage as PNG put alphadata of tempImage into theAlphaData ## DEFINE GRID put width of tempImage into theColumnCount put the height of tempImage into theRowCount delete tempImage reset the templateImage unlock screen ## LOOP THROUGH ALPHA DATA LOOKING FOR ## PIXELS THAT MEET VISIBILITY THRESHOLD ( 5) (right and left) ## or lines that contain non null = threshold 0 characters (top and bottom) ## make a variable (taBlancLine) the size of the width of the image, filled with binary null to compare it to the alphaData later put numToChar(0) into tNull put into taBlancLIne repeat theColumnCount put tNull after taBlancLine end repeat -- tRealRect will hold the bounding rect of the letters put 0,0,0,0 into tRealRect -- go by row from top to bottom, if a row is not all null in the alphaData then get the row number and bail out repeat with i = 0 to theRowCount - 1 if char (theColumnCount * i +1) to (theColumnCount * i + theColumnCount) of theAlphaData taBlancLIne then put i into item 2 of tRealRect exit repeat end if end repeat -- go by row from bottom to top, if a row is not all null in the alphaData then get the row number and bail out repeat with i = theRowCount - 1 down to 0 if char (theColumnCount * i +1) to (theColumnCount * i + theColumnCount) of theAlphaData taBlancLIne then put i +1 into item 4 of tRealRect exit repeat end if end repeat -- get the first alphapixel 5 from left to the right, get the column number and get out put false into tExit repeat with i = 1 to theColumnCount repeat with j = 0 to theRowCount - 1 if charToNum(char i + (j * theColumnCount) of theAlphaData) 5 then put i -1 into item 1 of tRealRect put true into tExit exit repeat end if end repeat if tExit then exit repeat end repeat -- get the first alphapixel 5 from right to left, get the column number and get out put false into tExit repeat with i = theColumnCount down to 1 repeat with j = theRowCount - 1 down to 0 if charToNum(char i + (j * theColumnCount) of theAlphaData) 5 then put i - 1 into item 3 of tRealRect put true into tExit exit repeat end if end repeat if tExit then exit repeat end repeat put the left of pField into tLeft add tLeft to item 1 of tRealRect add tLeft to item 3 of tRealRect put the top of pField into tTop add tTop to item 2 of tRealRect add tTop to item 4 of tRealRect return tRealRect end bnTextRect - Kind regards Bernd -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/What-is-up-with-FormattedHeight-tp4360344p4377624.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: What is up with FormattedHeight?
On 06/02/2012 03:30, Howard Bornstein wrote: I need to find the smallest rectangle that will enclose a line of text of arbitrary text size in a field. I thought I could use formattedheight and formattedwidth to do this but it doesn't seem to be working. I'm very perplexed too. Instead of worrying about what is/is not added to the text image, fonts, screen smoothing, margins, whatever (itis bound to have a platform-specific element to it), I figured Why not just ask the bits? So, I wrote a script (http://its.ec/static/testfield.livecode.zip) to investigate. It takes a snapshot of the field and puts it into a new image. Step through the bits of that image, and we should be able to say exactly where the text begins and ends, right? Only...it doesn't work as I've written it. No pixels are found. Ah, okay, maybe I didn't understand something, so I added a graphic from a PNG, and did the search on that, and it finds the pixels very easily. Same code, only the name has been changed. Different result. Clearly, there's something I don't understand at work here. Can anyone see what I've done wrong (and help Howard too?) On the plus side, it does this /very/ quickly. I was surprised at how fast stepping through the pixels of the graphic in a loop actually is. -Ken ___ 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: What is up with FormattedHeight?
Hi Ken: The following function does what you propose using a transitional image and gets pretty close. It requires the long id of the target field, and only works on transparent fields. You'd have to add additional code to convert the non-text portion of the field to alphaData, or temporarily convert the field to transparent and restore after capturing the text rect. function tmTextRect pField lock screen ## CREATE IMAGE WITH ALPHADATA reset the templateImage set lineSize of the templateImage to 0 create image put long id of it into tempImage do export snapshot from pField to tempImage as PNG put alphadata of tempImage into theAlphaData ## DEFINE GRID put width of tempImage into theColumnCount delete tempImage reset the templateImage unlock screen ## LOOP THROUGH ALPHA DATA LOOKING FOR ## PIXELS THAT MEET VISIBILITY THRESHOLD ( 5) put 1 into theRowNum put 0 into theColumnNum put 0,0,0,0 into theRect repeat for each char theByte in theAlphaData add 1 to theColumnNum put charToNum(theByte) into theValue if theValue 5 then if item 1 of theRect is 0 then put theColumnNum into item 1 of theRect put theRowNum into item 2 of theRect put theColumnNum into item 3 of theRect put theRowNum into item 4 of theRect end if put min(theColumnNum, item 1 of theRect) into item 1 of theRect put min(theRowNum, item 2 of theRect) into item 2 of theRect put max(theColumnNum, item 3 of theRect) into item 3 of theRect put max(theRowNum, item 4 of theRect) into item 4 of theRect end if if theColumnNum = theColumnCount then add 1 to theRowNum put 0 into theColumnNum end if end repeat add left of pField to item 1 of theRect add left of pField to item 3 of theRect add top of pField to item 2 of theRect add top of pField to item 4 of theRect return theRect end tmTextRect Regards, Scott Rossi Creative Director Tactile Media, UX Design Recently, Ken Corey wrote: On 06/02/2012 03:30, Howard Bornstein wrote: I need to find the smallest rectangle that will enclose a line of text of arbitrary text size in a field. I thought I could use formattedheight and formattedwidth to do this but it doesn't seem to be working. I'm very perplexed too. Instead of worrying about what is/is not added to the text image, fonts, screen smoothing, margins, whatever (itis bound to have a platform-specific element to it), I figured Why not just ask the bits? ___ 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: What is up with FormattedHeight?
Thanks for your reply. As a graphic designer, I know about ascenders, descenders, x-height, etc. However, I had thought that formattedHeight adjusted the field height to the size of the text being displayed, not to the min and max of the entire type face. I created a field with the entire extended ascii set in it and chose formatted height. While the bottom border hit the descenders, the upper border still had noticeable space above the highest character in the full character set. It turns out that this is because of the textheight property. This sets the vertical distance between one baseline and the next. This is set by default to 4*textsize/3 in order to provide a reasonable distance between lines (i.e. the leading). In order to make the formattedheight fit (almost) properly around the full range of a typeface you have to set the fixedLineHeight to true and then set the textheight to the same value as the textsize (rendering the effective leading as zero). However, it's more complicated than that. The proper display of text is a field is also contingent upon the field margins. If you set the margins to 0, the descenders start to get cut off when the text size is around 40 points. LC tries to make this invisible to the average user by setting the default margins to 8 (they recommend nothing less than 2 in order to take into account the focus border of the field). However, formattedHeight doesn't automatically adjust these margins for you so that the text is always displayed properly. You have to do this manually. So to recap, it appears the the formattedHeight property determines the displayable height of text in a field based on the metrics of the entire type face, not just the type that is displayed. It uses the textheight property (if set) and the margins properties (if set) as part of the soup that gets mixed together when displaying type. At large type sizes, the settings for the margins don't seem to be predictable to make sure that text is not cut off at the bottom. Given this, the only value I can see for formattedHeight is that it guarantees that the field will provide sufficient room to display the type. That's about it. And even that breaks down with large type sizes and small margins. Since LC does ultimately display the text as graphics on the computer, I had hoped it would have sufficient information to know exactly where the text boundaries are, but if it is using the operating system to actually display the text, then it probably wouldn't have this level of pixel-resolution information available. So it appears that it will not be easy to determine the minimum rectangle to encase text of any given font at any given size. I still have a couple of ideas to approximate this but if anyone else wants to take up the challenge, I'd be interested to hear what you come up with. Thanks for all the replies. On Mon, Feb 6, 2012 at 1:13 AM, Paul Hibbert l...@pbh.on-rev.com wrote: Howard, Why doesn't the formattedHeight of a field just do this automatically? Why does it include extra space at the top and bottom of the field? What are the relationships among text size, text height, and field height that will allow the field to adjust to exactly the size of the text regardless of the text size. There is a great deal more information contained in any font than the characters you see on screen. 1234 as you used for your test are all similar height characters, but consider chars like 'Å' and 'g' that need more room to display their information. Each character is sat on a baseline, but has clear space above and below so they are readable when typed into a paragraph, 100 pt type doesn't measure 100 points from the bottom of an individual character to it's the top, but is more often (not always) measured from the top of the highest ascender within the font to the bottom of the lowest descender of all the characters within the font, so you are not seeing the full picture with typing '1234'. Every font has it's own totally unique set of relationships and parameters for baseline, line height, x-height, ascenders, descenders etc. So, as you can probably imagine, any adjustments you make for say Helvetica will be totally different for a font like Brush Script. From my experience of working with type for over 35 years, both off and on computers, I really don't think LiveCode (or any other application) could do what you are asking without first converting the displayed text to a graphic (either vector or bitmap) and then processing the resulting information. Regards, Paul ___ 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
Re: What is up with FormattedHeight?
Right. As I've been able to determine, the textheight is used to create the leading and the formattedheight uses the font metrics, the textheight (if set) and the field margins (if set). On Mon, Feb 6, 2012 at 9:09 AM, Bob Sneidar b...@twft.com wrote: If you have ever had to edit type faces, you would see that this space is necessary. It used to be called leading (not lead as you would a dog but lead as in a bit of lead inserted between lines of type in a press). Without leading, type in a paragraph would be much more difficult to read. There needs to be room for the height of the ascender the body, the tail and the leading. The sum of all that is the formatted height. Bob On Feb 5, 2012, at 7:30 PM, Howard Bornstein wrote: I need to find the smallest rectangle that will enclose a line of text of arbitrary text size in a field. I thought I could use formattedheight and formattedwidth to do this but it doesn't seem to be working. The dictionary says about FormattedHeight: Use the *formattedHeight* property to determine how much vertical space an object needs. The *formattedHeight* of a chunk in a field is the amount of vertical space that portion of the field's text requires That's not what I get. If you'd like to follow along at home, here are some simple steps to show what I mean: Create a field in LC. set the showborder to true Set the border to 1 (this is only to show what LC thinks is the boundary of the field) Set the 3D to false set the margins to 0,0,0,0 Set the fixedlineheight to off Set the textfont to Helvetica Set the textsize to 100 Type in the following into the field 1234 Go to the size and positioning tab of the object inspector and click both Fit Content buttons for width and height. I would have expected the border to tighten down to include the text and no more. But instead, look at all that space at the top—and a fair amount of space at the bottom. Why is that space considered part of the height of the text? I can gain what I want by manually adjusting a number of properties. If I use the fixed line height property, I get a little more control, although, as far as I can tell, formattedheight should work without it, but it doesn't. If I turn on the fixed line height (i.e. the textheight property) in the inspector (with the configuration I described above), it is automatically set to a text height of 93 and the text jumps up to the top of the bounding box (I've got nice screen shots of all this but I seem to remember that we're not supposed to use attachments or images on this list). If I click Fit Content for height at this point, the box closes down and gets rid of some, but not all, of the space at the bottom. If I adjust the field height value to 73, I can finally get the bounding box to match the height of the text. This is what I am looking for. I am trying to figure out the relationship of settings which will always produce a bounding box with this level of tightness for any size text (I am ignoring the extra space on the left of the field for now). I need to be able to do this under script control. If I go through the same exercise but set the text size to 200 points, I can again adjust things so that the bounding box only encloses the text with no additional space, but I can't find any clear relationship between the settings for 100 points and 200 points. So my questions are these: Why doesn't the formattedHeight of a field just do this automatically? Why does it include extra space at the top and bottom of the field? What are the relationships among text size, text height, and field height that will allow the field to adjust to exactly the size of the text regardless of the text size. Please let me know if I'm totally missing the point about formattedHeight or if there is something else obvious that has eluded me. -- 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 ___ 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: What is up with FormattedHeight?
One thing I use it for is programmatically setting the height of menu buttons. I find the default size to be too large for a busy form, so I set the height to the formattedHeight of the text of the button. I have a utility that drops a field, button or menu onto a card and links it to a SQL column in a table that the card is linked to. Bob On Feb 8, 2012, at 1:26 PM, Howard Bornstein wrote: Given this, the only value I can see for formattedHeight is that it guarantees that the field will provide sufficient room to display the type. That's about it. And even that breaks down with large type sizes and small margins. ___ 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: What is up with FormattedHeight?
That makes sense. I was complaining about formattedHeight for fields. For buttons it seems useful. On Wed, Feb 8, 2012 at 2:26 PM, Bob Sneidar b...@twft.com wrote: One thing I use it for is programmatically setting the height of menu buttons. I find the default size to be too large for a busy form, so I set the height to the formattedHeight of the text of the button. I have a utility that drops a field, button or menu onto a card and links it to a SQL column in a table that the card is linked to. Bob On Feb 8, 2012, at 1:26 PM, Howard Bornstein wrote: Given this, the only value I can see for formattedHeight is that it guarantees that the field will provide sufficient room to display the type. That's about it. And even that breaks down with large type sizes and small margins. ___ 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: What is up with FormattedHeight?
Hi Howard, Interesting.. I've just tried this and can confirm your findings. What I think your seeing is the natural space that is built around the font, this is usually more pronounced in the verticle padding than the horizontal. To see what I mean, try changing the font type then refit the contents, notice how the verticle padding changes. This is a function of the font itself and not I believe a problem with LiveCode. See here for a pictorial representation: http://slodive.com/wp-content/uploads/2011/07/helvetica/helvetica-font-download.jpg http://slodive.com/wp-content/uploads/2011/07/helvetica/helvetica-font-download.jpg With Helvetica at 100pt I've found that margins of -5, -20,-5,-20 work well, but only at 100pt. To get a consistent removal of padding for all font sizes ( for one type font) you will need to work out the ratio of the natural padding to the size of the font and calculate and update the margins for each new font size. - Andy Piddock My software never has bugs. It just develops random features. PointandSee is a FREE simple but full featured under cursor colour picker / finder. http://www.pointandsee.co.uk - made with LiveCode (v1.4.1 released 26/08/2011) -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/What-is-up-with-FormattedHeight-tp4360344p4360697.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-livecode 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: What is up with FormattedHeight?
Howard, Why doesn't the formattedHeight of a field just do this automatically? Why does it include extra space at the top and bottom of the field? What are the relationships among text size, text height, and field height that will allow the field to adjust to exactly the size of the text regardless of the text size. There is a great deal more information contained in any font than the characters you see on screen. 1234 as you used for your test are all similar height characters, but consider chars like 'Å' and 'g' that need more room to display their information. Each character is sat on a baseline, but has clear space above and below so they are readable when typed into a paragraph, 100 pt type doesn't measure 100 points from the bottom of an individual character to it's the top, but is more often (not always) measured from the top of the highest ascender within the font to the bottom of the lowest descender of all the characters within the font, so you are not seeing the full picture with typing '1234'. Every font has it's own totally unique set of relationships and parameters for baseline, line height, x-height, ascenders, descenders etc. So, as you can probably imagine, any adjustments you make for say Helvetica will be totally different for a font like Brush Script. From my experience of working with type for over 35 years, both off and on computers, I really don't think LiveCode (or any other application) could do what you are asking without first converting the displayed text to a graphic (either vector or bitmap) and then processing the resulting information. Regards, Paul ___ 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: What is up with FormattedHeight?
If you have ever had to edit type faces, you would see that this space is necessary. It used to be called leading (not lead as you would a dog but lead as in a bit of lead inserted between lines of type in a press). Without leading, type in a paragraph would be much more difficult to read. There needs to be room for the height of the ascender the body, the tail and the leading. The sum of all that is the formatted height. Bob On Feb 5, 2012, at 7:30 PM, Howard Bornstein wrote: I need to find the smallest rectangle that will enclose a line of text of arbitrary text size in a field. I thought I could use formattedheight and formattedwidth to do this but it doesn't seem to be working. The dictionary says about FormattedHeight: Use the *formattedHeight* property to determine how much vertical space an object needs. The *formattedHeight* of a chunk in a field is the amount of vertical space that portion of the field's text requires That's not what I get. If you'd like to follow along at home, here are some simple steps to show what I mean: Create a field in LC. set the showborder to true Set the border to 1 (this is only to show what LC thinks is the boundary of the field) Set the 3D to false set the margins to 0,0,0,0 Set the fixedlineheight to off Set the textfont to Helvetica Set the textsize to 100 Type in the following into the field 1234 Go to the size and positioning tab of the object inspector and click both Fit Content buttons for width and height. I would have expected the border to tighten down to include the text and no more. But instead, look at all that space at the top—and a fair amount of space at the bottom. Why is that space considered part of the height of the text? I can gain what I want by manually adjusting a number of properties. If I use the fixed line height property, I get a little more control, although, as far as I can tell, formattedheight should work without it, but it doesn't. If I turn on the fixed line height (i.e. the textheight property) in the inspector (with the configuration I described above), it is automatically set to a text height of 93 and the text jumps up to the top of the bounding box (I've got nice screen shots of all this but I seem to remember that we're not supposed to use attachments or images on this list). If I click Fit Content for height at this point, the box closes down and gets rid of some, but not all, of the space at the bottom. If I adjust the field height value to 73, I can finally get the bounding box to match the height of the text. This is what I am looking for. I am trying to figure out the relationship of settings which will always produce a bounding box with this level of tightness for any size text (I am ignoring the extra space on the left of the field for now). I need to be able to do this under script control. If I go through the same exercise but set the text size to 200 points, I can again adjust things so that the bounding box only encloses the text with no additional space, but I can't find any clear relationship between the settings for 100 points and 200 points. So my questions are these: Why doesn't the formattedHeight of a field just do this automatically? Why does it include extra space at the top and bottom of the field? What are the relationships among text size, text height, and field height that will allow the field to adjust to exactly the size of the text regardless of the text size. Please let me know if I'm totally missing the point about formattedHeight or if there is something else obvious that has eluded me. -- 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 ___ 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
What is up with FormattedHeight?
I need to find the smallest rectangle that will enclose a line of text of arbitrary text size in a field. I thought I could use formattedheight and formattedwidth to do this but it doesn't seem to be working. The dictionary says about FormattedHeight: Use the *formattedHeight* property to determine how much vertical space an object needs. The *formattedHeight* of a chunk in a field is the amount of vertical space that portion of the field's text requires That's not what I get. If you'd like to follow along at home, here are some simple steps to show what I mean: Create a field in LC. set the showborder to true Set the border to 1 (this is only to show what LC thinks is the boundary of the field) Set the 3D to false set the margins to 0,0,0,0 Set the fixedlineheight to off Set the textfont to Helvetica Set the textsize to 100 Type in the following into the field 1234 Go to the size and positioning tab of the object inspector and click both Fit Content buttons for width and height. I would have expected the border to tighten down to include the text and no more. But instead, look at all that space at the top—and a fair amount of space at the bottom. Why is that space considered part of the height of the text? I can gain what I want by manually adjusting a number of properties. If I use the fixed line height property, I get a little more control, although, as far as I can tell, formattedheight should work without it, but it doesn't. If I turn on the fixed line height (i.e. the textheight property) in the inspector (with the configuration I described above), it is automatically set to a text height of 93 and the text jumps up to the top of the bounding box (I've got nice screen shots of all this but I seem to remember that we're not supposed to use attachments or images on this list). If I click Fit Content for height at this point, the box closes down and gets rid of some, but not all, of the space at the bottom. If I adjust the field height value to 73, I can finally get the bounding box to match the height of the text. This is what I am looking for. I am trying to figure out the relationship of settings which will always produce a bounding box with this level of tightness for any size text (I am ignoring the extra space on the left of the field for now). I need to be able to do this under script control. If I go through the same exercise but set the text size to 200 points, I can again adjust things so that the bounding box only encloses the text with no additional space, but I can't find any clear relationship between the settings for 100 points and 200 points. So my questions are these: Why doesn't the formattedHeight of a field just do this automatically? Why does it include extra space at the top and bottom of the field? What are the relationships among text size, text height, and field height that will allow the field to adjust to exactly the size of the text regardless of the text size. Please let me know if I'm totally missing the point about formattedHeight or if there is something else obvious that has eluded me. -- 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 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 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 ___ 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
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! 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 -- 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
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
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
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: 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
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 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 __**_ 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
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
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 __**_ 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
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
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
formattedheight and formattedwidth
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 Pete Molly's Revenge http://www.mollysrevenge.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
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
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
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
formattedHeight and scrollbars
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
