Re: Group resizing.
Oh good, I was hoping I wasn’t the only one. — Scott > On May 3, 2020, at 11:28 AM, Alex Tweedly via use-livecode > wrote: > > > I can now get back to my "10-minute cleanup task" that I started 8 hours ago > :-) > > Alex. ___ 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: DataView and DataView Tree Updates
On Sun, May 3, 2020 at 1:11 PM JeeJeeStudio via use-livecode < use-livecode@lists.runrev.com> wrote: > your dataview demo throws an error on line 313: it's missing an before > or into or after: > I just downloaded the version 0.4.0 from the Releases page and don't get any errors. https://github.com/trevordevore/dataview_demo/releases Can you provide some more details about what you tested? There was a missing "into" int the dataview_dbcursor submdoule but that was fixed before I posted the update. Here is the commit: https://github.com/trevordevore/levurehelper-database_dbcursor/commit/59cba88e26c17dac819f7137054868b71dcf6617 -- Trevor DeVore ScreenSteps - https://www.screensteps.com Levure App Framework for LiveCode - https://github.com/trevordevore/levure/ LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder ___ 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: Group resizing.
No, I don't, and that's probably what I should be doing. I had not expected that changing the LEFT of a control would change both X *and* Y coordinates of the enclosing group - but that is what seems to happen; and that at least makes sense - any change to the control causes an adjustment to both dimensions of the enclosing group. The surprise now is that changing the WIDTH of that control (which I do in the previous statement), which also could change both left & right X coords of the control, didn't also have that effect. Maybe because in this case the width setting didn't actually change the values - so it optimized out actually setting them, or adjusting to allow for it. Anyway - thanks Brian, I can now get back to my "10-minute cleanup task" that I started 8 hours ago :-) Alex. On 03/05/2020 16:38, Brian Milby via use-livecode wrote: Do you have the group size/position locked (lockLocation property)? If not, moving a control could change the rect. Thanks, Brian On May 3, 2020, 10:28 AM -0400, Håkan Liljegren via use-livecode , wrote: You probably need to lock messages in the beginning of your resizeControl. Otherwise the group will adapt to your resizing of your controls. I usually begin with both lock messages and lock screen, but the last is more for optimization. Håkan On 3 May 2020, 16:22 +0200, Alex Tweedly via use-livecode , wrote: I realized after the discussion last week about resizing that I was missing the benefits of "resizeControl" being sent to each group, so I changed one of my resize handlers to make use of groups (adding a few groups along the way). And it all went wrong :-( Eventually I traced it down to the following ... and don't know if I'm missing something or if I've bumped into a bug. The resize handler is on resizeControl set the width of field "list titles" of me to the width of me - 20 put "B" && the rect of me && the bottom of me after msg set the left of field "list titles" of me to 10 put "C" && the rect of me && the bottom of me after msg local tR put 10, the top of me, the right of me -10, the bottom of me-10 into tR set the rect of fld "List" of me to tR end resizeControl Note the two "put ... msg" statements. - for no reason I can figure out, the "bottom of me" changes between these two statements. Here's the output from the message box: B 5,32,331,468 468 C 6,32,325,2618 2618 B 5,32,331,471 471 C 5,32,320,2622 2622 B 5,32,331,473 473 C 5,32,320,2626 2626 If I comment out that "set the left of ..." statement, all apparently works as expected. Why should setting the 'left' of a control change the bottom of its enclosing group ? And why change it to an apparently silly value ? -- Alex. ___ 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 ___ 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: Group resizing.
Thanks, but no, I can't do that. lock messages will prevent the "resizeControl" being fired for any sub-groups whose co-ordinates get changed, so it would prevent proper layout for them. 'lock messages' is good if you have all your controls directly re-positioned within your resize handler - but disallows hierarchy (which is the feature I'm trying to take advantage of here). lock screen is of course a good optimization - thanks. Alex. On 03/05/2020 15:26, ha...@exformedia.se wrote: You probably need to lock messages in the beginning of your resizeControl. Otherwise the group will adapt to your resizing of your controls. I usually begin with both lock messages and lock screen, but the last is more for optimization. Håkan On 3 May 2020, 16:22 +0200, Alex Tweedly via use-livecode , wrote: I realized after the discussion last week about resizing that I was missing the benefits of "resizeControl" being sent to each group, so I changed one of my resize handlers to make use of groups (adding a few groups along the way). And it all went wrong :-( Eventually I traced it down to the following ... and don't know if I'm missing something or if I've bumped into a bug. The resize handler is on resizeControl set the width of field "list titles" of me to the width of me - 20 put "B" && the rect of me && the bottom of me after msg set the left of field "list titles" of me to 10 put "C" && the rect of me && the bottom of me after msg local tR put 10, the top of me, the right of me -10, the bottom of me-10 into tR set the rect of fld "List" of me to tR end resizeControl Note the two "put ... msg" statements. - for no reason I can figure out, the "bottom of me" changes between these two statements. Here's the output from the message box: B 5,32,331,468 468 C 6,32,325,2618 2618 B 5,32,331,471 471 C 5,32,320,2622 2622 B 5,32,331,473 473 C 5,32,320,2626 2626 If I comment out that "set the left of ..." statement, all apparently works as expected. Why should setting the 'left' of a control change the bottom of its enclosing group ? And why change it to an apparently silly value ? -- Alex. ___ 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: DataView and DataView Tree Updates
Hi Trevore, FYI your dataview demo throws an error on line 313: it's missing an before or into or after: probably an into *put _rowOfId(tId) tRow* put _rowOfId(tId) into Row Op 2-5-2020 om 19:42 schreef Trevor DeVore via use-livecode: Hi, I've updated the DataView and DataView Tree code in my GitHub repos with a script that will load all of the necessary files for developers who are not using the Levure framework. You will find updated instructions in the README, a link to the latest release, and a link to a demo project showing what they can do at the following links: https://github.com/trevordevore/levurehelper-dataview https://github.com/trevordevore/levurehelper-dataview_tree ___ 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: DataView and DataView Tree Updates
Thanks! Going to take a look. Op 2-5-2020 om 19:42 schreef Trevor DeVore via use-livecode: Hi, I've updated the DataView and DataView Tree code in my GitHub repos with a script that will load all of the necessary files for developers who are not using the Levure framework. You will find updated instructions in the README, a link to the latest release, and a link to a demo project showing what they can do at the following links: https://github.com/trevordevore/levurehelper-dataview https://github.com/trevordevore/levurehelper-dataview_tree ___ 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: Most obscure HC question
Thanks for the suggestions. The ideas about resizing the card window is what I had already tried. The scroller window only allows the window to be made smaller, it won’t go bigger. Double clicking in the scroller makes the card window hide or show, it doesn’t do the expected make the window the size of the card. I had tried changing the APPL to STAK, and that does let me open it in HyperCard. The card window is the correct size when I do that. The stack ends up locking up though, because it does use xcmds, and those are resources in the standalone app version, they’re not in HyperCard. Deleting most of the resources, not the xcmdd and xfcns, does make the stack work in HyperCard, but I lost a lot of the graphics doing that. I found that I could edit the script using a hex editor, and put in a line to set the size of the card (replacing a line that wasn’t vital). That broke the stack, but I may try it again. I added script to show the message box, but it seems that the standalone player doesn’t include the HyperTalk interpreter, attempts to set the rect of the card failed, as would anything I typed. I will keep trying other ideas. > On May 3, 2020, at 9:40 AM, Craig Newman via use-livecode > wrote: > > Can you explicitly set the text of the card in an openCard handler? > > Craig Newman > > Sent from my iPhone > >> On May 2, 2020, at 7:06 PM, Colin Holgate via use-livecode >> wrote: >> >> I fear that the HyperCard group in Yahoo may be lost. Please let me know if >> that isn’t true. >> >> But between you all you may remember something that will help me. I have a >> standalone HC application, and it opens with a window that shows that you >> are only seeing part of the card window. The card window doesn’t resize, and >> I can’t remember how to make it be bigger. Here’s things that didn’t work: >> >> Setting a ton of memory. >> Setting Monitors to match the card size. >> Resizing the preview rectangle. You can only resize it smaller. >> Resizing the card window. >> Clicking the zoom box. >> >> As it’s a standalone application I can’t easily get at the stack, but feel >> sure there was a way to hack the stack out of a standalone. >> >> Anyway, please enjoy the challenge of remembering this far back! >> >> ___ >> 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: Most obscure HC question
Can you explicitly set the text of the card in an openCard handler? Craig Newman Sent from my iPhone > On May 2, 2020, at 7:06 PM, Colin Holgate via use-livecode > wrote: > > I fear that the HyperCard group in Yahoo may be lost. Please let me know if > that isn’t true. > > But between you all you may remember something that will help me. I have a > standalone HC application, and it opens with a window that shows that you are > only seeing part of the card window. The card window doesn’t resize, and I > can’t remember how to make it be bigger. Here’s things that didn’t work: > > Setting a ton of memory. > Setting Monitors to match the card size. > Resizing the preview rectangle. You can only resize it smaller. > Resizing the card window. > Clicking the zoom box. > > As it’s a standalone application I can’t easily get at the stack, but feel > sure there was a way to hack the stack out of a standalone. > > Anyway, please enjoy the challenge of remembering this far back! > > ___ > 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: Group resizing.
Do you have the group size/position locked (lockLocation property)? If not, moving a control could change the rect. Thanks, Brian On May 3, 2020, 10:28 AM -0400, Håkan Liljegren via use-livecode , wrote: > You probably need to lock messages in the beginning of your resizeControl. > Otherwise the group will adapt to your resizing of your controls. I usually > begin with both lock messages and lock screen, but the last is more for > optimization. > > Håkan > On 3 May 2020, 16:22 +0200, Alex Tweedly via use-livecode > , wrote: > > I realized after the discussion last week about resizing that I was > > missing the benefits of "resizeControl" being sent to each group, so I > > changed one of my resize handlers to make use of groups (adding a few > > groups along the way). > > > > And it all went wrong :-( > > > > Eventually I traced it down to the following ... and don't know if I'm > > missing something or if I've bumped into a bug. > > > > The resize handler is > > > > > on resizeControl > > > set the width of field "list titles" of me to the width of me - 20 > > > put "B" && the rect of me && the bottom of me after msg > > > set the left of field "list titles" of me to 10 > > > put "C" && the rect of me && the bottom of me after msg > > > local tR > > > put 10, the top of me, the right of me -10, the bottom of me-10 into tR > > > set the rect of fld "List" of me to tR > > > end resizeControl > > > > Note the two "put ... msg" statements. - for no reason I can figure out, > > the "bottom of me" changes between these two statements. Here's the > > output from the message box: > > > > > B 5,32,331,468 468 > > > C 6,32,325,2618 2618 > > > B 5,32,331,471 471 > > > C 5,32,320,2622 2622 > > > B 5,32,331,473 473 > > > C 5,32,320,2626 2626 > > > > > If I comment out that "set the left of ..." statement, all apparently > > works as expected. > > > > Why should setting the 'left' of a control change the bottom of its > > enclosing group ? > > > > And why change it to an apparently silly value ? > > > > -- Alex. > > > > > > ___ > > 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: Group resizing.
You probably need to lock messages in the beginning of your resizeControl. Otherwise the group will adapt to your resizing of your controls. I usually begin with both lock messages and lock screen, but the last is more for optimization. Håkan On 3 May 2020, 16:22 +0200, Alex Tweedly via use-livecode , wrote: > I realized after the discussion last week about resizing that I was > missing the benefits of "resizeControl" being sent to each group, so I > changed one of my resize handlers to make use of groups (adding a few > groups along the way). > > And it all went wrong :-( > > Eventually I traced it down to the following ... and don't know if I'm > missing something or if I've bumped into a bug. > > The resize handler is > > > on resizeControl > > set the width of field "list titles" of me to the width of me - 20 > > put "B" && the rect of me && the bottom of me after msg > > set the left of field "list titles" of me to 10 > > put "C" && the rect of me && the bottom of me after msg > > local tR > > put 10, the top of me, the right of me -10, the bottom of me-10 into tR > > set the rect of fld "List" of me to tR > > end resizeControl > > Note the two "put ... msg" statements. - for no reason I can figure out, > the "bottom of me" changes between these two statements. Here's the > output from the message box: > > > B 5,32,331,468 468 > > C 6,32,325,2618 2618 > > B 5,32,331,471 471 > > C 5,32,320,2622 2622 > > B 5,32,331,473 473 > > C 5,32,320,2626 2626 > > > If I comment out that "set the left of ..." statement, all apparently > works as expected. > > Why should setting the 'left' of a control change the bottom of its > enclosing group ? > > And why change it to an apparently silly value ? > > -- Alex. > > > ___ > 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
Group resizing.
I realized after the discussion last week about resizing that I was missing the benefits of "resizeControl" being sent to each group, so I changed one of my resize handlers to make use of groups (adding a few groups along the way). And it all went wrong :-( Eventually I traced it down to the following ... and don't know if I'm missing something or if I've bumped into a bug. The resize handler is on resizeControl set the width of field "list titles" of me to the width of me - 20 put "B" && the rect of me && the bottom of me after msg set the left of field "list titles" of me to 10 put "C" && the rect of me && the bottom of me after msg local tR put 10, the top of me, the right of me -10, the bottom of me-10 into tR set the rect of fld "List" of me to tR end resizeControl Note the two "put ... msg" statements. - for no reason I can figure out, the "bottom of me" changes between these two statements. Here's the output from the message box: B 5,32,331,468 468 C 6,32,325,2618 2618 B 5,32,331,471 471 C 5,32,320,2622 2622 B 5,32,331,473 473 C 5,32,320,2626 2626 If I comment out that "set the left of ..." statement, all apparently works as expected. Why should setting the 'left' of a control change the bottom of its enclosing group ? And why change it to an apparently silly value ? -- Alex. ___ 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
