Re: 3WDevolution question
Frankly, I would prefer the ide tools palette and the Devo tools palette overlap at will. One or the other can be in front, overlapped or not. I generally only use the ide tools when creating UI objects, so most of the time it’s invisible. Currently, to get the Devo palette to go as far left as I want, I just drag the IDE tools palette to center screen, then back. Best, Bill William Prothero http://es.earthednet.org > On Sep 7, 2018, at 9:44 PM, Richard Gaskin via use-livecode > wrote: > > Brian Milby wrote: > > > FWIW... > > I see the same thing on Mac where Devolution will not move past the > > tool palette. > > More interestingly, when you see the windowBoundingRect altered by the > placement of the IDE's tool palette, does a maximized window respect the new > windowBoundingRect as it does on Windows, or ignore it as it does on Linux? > > > > One possible solution would be to add the rect of Devolution to the > > prefs and restore regardless of the bounding rect. This would allow > > the tool palette to be positioned over Devolution since you probably > > only actively use one at a time (if desired anyway). > > I could add all sorts of additional geometry for the edge case in which > someone wants to have both the devo window and the tool palette open at the > same time AND in a position which prevents use of one or the other > > Or the IDE team could just not monkey with the windowBoundingRect based on > the occasional position of a single window which is different from what > happens in other positions, different from what happens in other windows, and > different from what happens in other apps. > > Which would seem more beneficial for the larger number of LC scripters? > > -- > 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 ___ 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: 3WDevolution question
On Fri, Sep 7, 2018 at 11:45 PM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Brian Milby wrote: > > > FWIW... > > I see the same thing on Mac where Devolution will not move past the > > tool palette. > > More interestingly, when you see the windowBoundingRect altered by the > placement of the IDE's tool palette, does a maximized window respect the > new windowBoundingRect as it does on Windows, or ignore it as it does on > Linux? > > Mac is somewhat different. If you click the maximize control then you go into full screen mode for that window (no title bar, no menu, no dock). Palettes still appear over it (tools, Devolution, Navigator, DevTools, but not the menu button bar). You have to hold the option key when clicking the green dot to get the old behavior (which puts a `+` in it). Even then, it fills the entire screen (except it does not cover the dock). Same palette situation. > > > One possible solution would be to add the rect of Devolution to the > > prefs and restore regardless of the bounding rect. This would allow > > the tool palette to be positioned over Devolution since you probably > > only actively use one at a time (if desired anyway). > > I could add all sorts of additional geometry for the edge case in which > someone wants to have both the devo window and the tool palette open at > the same time AND in a position which prevents use of one or the other > > Or the IDE team could just not monkey with the windowBoundingRect based > on the occasional position of a single window which is different from > what happens in other positions, different from what happens in other > windows, and different from what happens in other apps. > > Which would seem more beneficial for the larger number of LC scripters? > > I was mainly talking about saving the position between launches like the tools palette does. I ended up putting the stack toplevel and moving to get it where I wanted and then saving. On my Linux VM, due to the screen size, I put it on the extreme right at the top (which due to the bug you filed, allows me to move it up to the top currently - next to the menu bar). When just testing, I relaunched LC and was able to move Devolution wherever I wanted (even over the menu button bar). I promptly put it all the way to the left and saved it :) I agree that the boundingrect stuff is a little frustrating. It's not like the menu goes edge to edge nor does the tool palette go top to bottom of the screen. Thanks, Brian ___ 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: 3WDevolution question
Brian Milby wrote: > FWIW... > I see the same thing on Mac where Devolution will not move past the > tool palette. More interestingly, when you see the windowBoundingRect altered by the placement of the IDE's tool palette, does a maximized window respect the new windowBoundingRect as it does on Windows, or ignore it as it does on Linux? > One possible solution would be to add the rect of Devolution to the > prefs and restore regardless of the bounding rect. This would allow > the tool palette to be positioned over Devolution since you probably > only actively use one at a time (if desired anyway). I could add all sorts of additional geometry for the edge case in which someone wants to have both the devo window and the tool palette open at the same time AND in a position which prevents use of one or the other Or the IDE team could just not monkey with the windowBoundingRect based on the occasional position of a single window which is different from what happens in other positions, different from what happens in other windows, and different from what happens in other apps. Which would seem more beneficial for the larger number of LC scripters? -- 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: Slow LC 9 Performance - Test Stack, Video, QA Report
Mark: > if sQty = "1234567" > by your account that should be a runtime error because > it's a comparison between a number and a string? In the original Root Loops code, I assume it should be a pure comparison of i (binary, such as +5.00...) with sQty (binary, +1234567.00...) so that native math would be used and no text string involved during the loop after it gets started. But in the "big calculations" variation, the code has many numbers-as-strings that get converted each time through the loop, and that makes quite a difference on LC 9; hardly any on 6. That is definitely worth looking into. I like your "not to trust the easy answers" philosophy! Any improvements under the hood will certainly get a lot of good use. Best wishes, Curry K. ___ 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: 3WDevolution question
FWIW... I see the same thing on Mac where Devolution will not move past the tool palette. One possible solution would be to add the rect of Devolution to the prefs and restore regardless of the bounding rect. This would allow the tool palette to be positioned over Devolution since you probably only actively use one at a time (if desired anyway). Thanks, Brian On Sep 7, 2018, 9:57 PM -0500, Richard Gaskin via use-livecode , wrote: > Mark Wieder wrote: > > > On 09/06/2018 07:10 PM, Richard Gaskin via use-livecode wrote: > > > > > Maximize a window when the tool palette is flush left, then restore, > > > then try again after the palette has been moved more toward screen > > > center. The changes the IDE makes to the windowBoundingRect should > > > be evident with that recipe on all platforms. > > > > All right. I see that, although I had to pull PowerTools out of the > > way to see the problem, since it only affects the built-in tools > > palette. I didn't see a problem with maximizing a stack, but > > devolution wouldn't move to the left past the right border of the > > tools palette. Are you seeing maximized stacks also being affected > > by this? > > Not on Linux. :) > > It seems an old bug has regressed - I've filed a new report: > https://quality.livecode.com/show_bug.cgi?id=21574 > > While the windowBoundingRect is currently ignored for standard style > windows on Linux, on MS Windows 10 the maximize behavior works as > expected, constrained withing the rect specified in that property. I > haven't checked on Mac, but assumed it hasn't broken there; if anyone > finds that it has feel free to add a note to that effect in the report. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.com http://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 ___ 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: Slow LC 9 Performance - Test Stack, Video, QA Report
On 09/07/2018 06:55 PM, Curry Kenworthy via use-livecode wrote: You guys might be right, but I doubt it. Here's one reason why. I took some care to make the math test a true math test. Notice in Root Loops: local sQty=1234567 add 0 to sQty --> make it a true number* I could be wrong, but I'm not convinced that's what actually happens. So if the next line is if sQty = "1234567" by your account that should be a runtime error because it's a comparison between a number and a string? Or does the comparison operator somehow convert the number back to a string to compare the two? I'm suspicious enough of the sleight-of-hand that underpins the use of unquoted string literals not to trust the easy answers, and to think that under the hood in the engine everything at the script level is an MCString until necessarily converted internally for computation. And then back again. But just guessing. -- Mark Wieder ahsoftw...@gmail.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: Slow LC 9 Performance - Test Stack, Video, QA Report
Me: > I took some care to make the math test a true math test. P.S. - I was careful about binary optimization for the original Root Loops math test, but the alternate shift-click test I added later (big calculations) didn't have that. Doing so makes hardly any difference for LC6, but it does help LC9 quite a bit. It brings the big calculations result on Windows down from 2x to 1.5x slower on my computer. That helps to separate the maths from the loops. Very good point Jerry/Mark; whether it's due to Unicode or not, conversion on 9 may be slower! But even with conversion happening inside a loop, the unoptimized big math was 2x slower whereas the main Root Loops test (always binary optimized) is 2.7x slower, as is an empty loop with i. So the loop itself, or especially the "with i" portion of it, might be part of the problem. I had previously tested a loop with no i (repeat sQty) and it was only 1.3 times slower. Hm. That could leave the incrementing and the comparison to sQty. One of those could be a culprit, or collectively maybe all 3 play a part; 1.3 ^ 3 = 2.2. Unfortunately I don't have any time to pursue more tests right now, plus I was determined at first to only provide the results and not speculate too much on causes. Breaking my rule here. :) But I hope we can get some great engine performance going soon, one way or another. Run well-optimized scripts on a very fast engine and we'd be blazing along nicely! Best wishes, Curry Kenworthy Custom Software Development LiveCode Training and Consulting http://livecodeconsulting.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: 3WDevolution question
Mark Wieder wrote: > On 09/06/2018 07:10 PM, Richard Gaskin via use-livecode wrote: > >> Maximize a window when the tool palette is flush left, then restore, >> then try again after the palette has been moved more toward screen >> center. The changes the IDE makes to the windowBoundingRect should >> be evident with that recipe on all platforms. > > All right. I see that, although I had to pull PowerTools out of the > way to see the problem, since it only affects the built-in tools > palette. I didn't see a problem with maximizing a stack, but > devolution wouldn't move to the left past the right border of the > tools palette. Are you seeing maximized stacks also being affected > by this? Not on Linux. :) It seems an old bug has regressed - I've filed a new report: https://quality.livecode.com/show_bug.cgi?id=21574 While the windowBoundingRect is currently ignored for standard style windows on Linux, on MS Windows 10 the maximize behavior works as expected, constrained withing the rect specified in that property. I haven't checked on Mac, but assumed it hasn't broken there; if anyone finds that it has feel free to add a note to that effect in the report. -- 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: Slow LC 9 Performance - Test Stack, Video, QA Report
Jerry: > Are the math routines doing unnecessary unicode interpretation? Mark: > Doing type conversion on the strings-that-are-not-strings > and then getting to the math functions. You guys might be right, but I doubt it. Here's one reason why. I took some care to make the math test a true math test. Notice in Root Loops: local sQty=1234567 add 0 to sQty --> make it a true number* put 0 into n repeat with i=1 to sQty add sqrt(i) to n end repeat * So sQty is already binary when the loop starts. The "1" is a string, but that only happens once and shouldn't matter. (In fact I started out with stuff like t1 just to be sure, and 0+0 into n, but it made no difference so I took it out. After one loop at most, i and n are now binary and should stay that way. Sqrt is acting upon i (binary), adding the result (binary) to n (binary) and comparing i to sQty (binary) so in theory no conversion should be taking place until the repeat is over. So in theory we're really testing the math between versions and not the conversion. Second reason: because (perhaps ironically) it turns out the text portions of LC, other than chunks, are actually performing better on tests than other parts. It's not my place to speculate, but maybe the attention given to the text handling code during Unicode did a lot of good! But I don't want to speculate too much; I'd better stick more to the stats. :) Best wishes, Curry Kenworthy Custom Software Development LiveCode Training and Consulting http://livecodeconsulting.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: Slow LC 9 Performance - Test Stack, Video, QA Report
> On Sep 7, 2018, at 6:27 PM, Mark Wieder via use-livecode > wrote: > > On 09/07/2018 06:18 PM, Jerry Jensen via use-livecode wrote: >> Just a quick wild thought: Are the math routines doing unnecessary unicode >> interpretation? > > That's my guess as well. > Doing type conversion on the strings-that-are-not-strings and then getting to > the math functions. Or even unnecessary multiple conversions within a complex math expression… .Jerry ___ 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: 3WDevolution question
On 09/06/2018 07:10 PM, Richard Gaskin via use-livecode wrote: Maximize a window when the tool palette is flush left, then restore, then try again after the palette has been moved more toward screen center. The changes the IDE makes to the windowBoundingRect should be evident with that recipe on all platforms. All right. I see that, although I had to pull PowerTools out of the way to see the problem, since it only affects the built-in tools palette. I didn't see a problem with maximizing a stack, but devolution wouldn't move to the left past the right border of the tools palette. Are you seeing maximized stacks also being affected by this? If others feel strongly that the windowBoundingRect should not be dynamically altered based on the position of a floating palette they're welcome to report it. I generally limit my own reports to engine issues beyond my ability to correct for, or things frequently raised by newcomers in the forums. Afaict this only affects devolution, and only the built-in tools palette seems to be the culprit, so I don't care much one way or the other. -- Mark Wieder ahsoftw...@gmail.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: Slow LC 9 Performance - Test Stack, Video, QA Report
On 09/07/2018 06:18 PM, Jerry Jensen via use-livecode wrote: Just a quick wild thought: Are the math routines doing unnecessary unicode interpretation? That's my guess as well. Doing type conversion on the strings-that-are-not-strings and then getting to the math functions. -- Mark Wieder ahsoftw...@gmail.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: Slow LC 9 Performance - Test Stack, Video, QA Report
Just a quick wild thought: Are the math routines doing unnecessary unicode interpretation? .Jerry > On Sep 7, 2018, at 6:11 PM, Mark Wieder via use-livecode > wrote: > > Otherwise (math especially) LC6 is much faster. ___ 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: Slow LC 9 Performance - Test Stack, Video, QA Report
On 09/07/2018 01:04 PM, Curry Kenworthy via use-livecode wrote: Nice to know that bright spot for Linux on the bigger lists and 64-bits! Mac and Windows performance both got 1.7 times worse on those, at least on my machines. I appreciate you testing it. I misread some of my data yesterday, and there are actually a few other places where LC9 is faster than LC6.7 on linux. And just for fun I loaded a 32-bit LC9 so it's a more fair comparison. Append 345678 Items texts (of 1280) 32bitLC6: 4894 32bitLC9: 3895 64bitLC9: 3271 Text Maxed 32bitLC6: 765 : 1018 32bitLC9: 494 : 1341 64bitLC9: 484 : 1469 (casesensitive) 32bitLC6: 760: 928 32bitLC9: 504 : 1308 64bitLC9: 494 : 1285 single-char search text 32bitLC6: 760 : 793 32bitLC9: 504 : 879 64bitLC9: 493 : 804 single-char search text (casesensitive) 32bitLC6: 761 : 743 32bitLC9: 504 : 817 64bitLC9: 511 : 797 Otherwise (math especially) LC6 is much faster. -- Mark Wieder ahsoftw...@gmail.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: This is disturbing!
> Bob S wrote:
> There is already a string keyword.
>
True. ‘Stringify()’ or ‘’evaluateAsString()’
It’s easy enough to write a function to force string comparisons for those rare
edge cases like "6. " is equal to "6.” where the engine automatically converts
the strings to numbers.
function compareAsStrings string1, string2
return string1 & "a" = string2 & "a"
end compareAsStrings
compareAsStrings("6. ","6.") returns FALSE.
Jim Lambert
___
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: Slow LC 9 Performance - Test Stack, Video, QA Report
Mark: > For appending 5 item texts, I see a 3x slowdown in LC9, > similar to your results. Thanks for sharing your Linux results! So that means on 3 different platforms (Mac, Win, Linux) using item chunks is 3x to 4x slower in LiveCode today than it was 2 years ago, for a short list of items. (And I just realized that some Mac people may have misunderstood that all this was just another Mac/Win type comparison, so I'll state it again clearly from a Mac-centric perspective.) LC on Mac today is 3 times slower than it was two years ago for arrays and items, and 2 times slower for math! At least on my Mac, assuming it holds true for your chip too. So we are all in this performance boat together, no matter your OS preference. You're affected. Moreover (as I demo'd in the video) using item chunks is slower in LiveCode today than using an array was 2 years ago! The old speed of items blew it away. That may surprise some of the people thinking they'll just use items; the ultra-fast option doesn't exist anymore. I'm very happy that arrays already are on LC's official radar, because they are extremely important and they are currently 2x-3x slower. That will help. Probably noticed, and on the radar, because Mac was disproportionately affected! Mac Mac Mac. :) But attention Mac people: Mac is every bit as affected (3.3x slower than before) by those slower chunks for a small list of items. (Big lists too, on Mac AFAIK.) So fixing arrays is only part of the solution. Items are pretty important too, especially when they are being emphasized as a route for optimizing code. Math and loops help too. > Append 345678 Items texts (of 1280): > LC6.7.11 (32-bit): 4894 ms > LC9.01rc3 (64-bit): 3271 ms Nice to know that bright spot for Linux on the bigger lists and 64-bits! Mac and Windows performance both got 1.7 times worse on those, at least on my machines. I appreciate you testing it. Best wishes, Curry K. ___ 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: The Visible Hilited Line of a Datagrid
The following is fruits of my labors. I am attempting to have a group of two buttons always vertically positioned center-aligned with the hilited line. Here is what I came up with: on setROControlLoc put the dgHilitedLine of me into tHilitedLine put item 1 of the dgVisibleLines of me into tFirstLine put (tHilitedLine - tFirstLine) into tRowOffset put the top of group "QuickNotes" into tGridTop put the dgProp ["header height"] of me into tHeaderHeight put the dgProp ["row height"] of me into tRowHeight put the loc of group "grpReorder" into tROControlLoc put tGridTop + tHeaderHeight + (tRowHeight * (tRowOffset)) + (tRowHeight /2) into tROControlCenter put tROControlCenter into item 2 of tROControlLoc set the loc of group "grpReorder" to tROControlLoc end setROControlLoc There is probably a much simpler and more elegant wat to go about it, but I can't discern it. I will post a sample stack later. It's pretty cool. The idea is to have a control for moving a line up or down in a datagrid. I considered a drag and drop but it's too much brain power, and this is much easier. Bob S > On Sep 7, 2018, at 11:06 , Trevor DeVore via use-livecode > wrote: > > Take a look at the dgVisibleLines property. Use dgHilitedLines > and dgVisibleLines to determine the offset. > > -- > Trevor DeVore ___ 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: The Visible Hilited Line of a Datagrid
Thanks Trevor! I swear I scoured the API and never saw that! Bob S > On Sep 7, 2018, at 11:06 , Trevor DeVore via use-livecode > wrote: > >> It must be late in the day, but I am having a hard time getting the >> VISIBLE hilited line of a table datagrid. I can do the math based on the >> scroll and all that, but what I want is for example, in a scrolled >> datagrid, the user clicks on the first visible line. I want to return 1, or >> if the second visible line I want to return 2. I was given to understand >> that when scrolling, the fields are drawn from scratch, but their names >> reflect their index and NOT their visible position in the scrolled grid! >> > > Take a look at the dgVisibleLines property. Use dgHilitedLines > and dgVisibleLines to determine the offset. > > -- > Trevor DeVore ___ 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: The Visible Hilited Line of a Datagrid
On Thu, Sep 6, 2018 at 6:38 PM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > It must be late in the day, but I am having a hard time getting the > VISIBLE hilited line of a table datagrid. I can do the math based on the > scroll and all that, but what I want is for example, in a scrolled > datagrid, the user clicks on the first visible line. I want to return 1, or > if the second visible line I want to return 2. I was given to understand > that when scrolling, the fields are drawn from scratch, but their names > reflect their index and NOT their visible position in the scrolled grid! > Take a look at the dgVisibleLines property. Use dgHilitedLines and dgVisibleLines to determine the offset. -- Trevor DeVore ScreenSteps www.screensteps.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: ANN: LC Documentation Cache Cleaner
On 09/06/2018 11:14 PM, James At The Hale via use-livecode wrote: Richard asks re the new extension store.. When? Well its initial offering is already here, see Jacque’s posts. As for when it will offer what was promised...probably sometime after Infinite Livecode has delivered the components and examples it promised or after DataGrid 2 is complete and delivered. Not holding my breathe. Yeah. See my post about the hard crash. I do see a 'store' of sorts on the website (https://livecode.com/extensions/) is that what you're referring to? That seems to be just a place to sell things. There's no apparent way to upload extensions and no similar link on the livecode.org site. No hint of community involvement. -- Mark Wieder ahsoftw...@gmail.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: ANN: LC Documentation Cache Cleaner
On 09/06/2018 09:02 PM, J. Landman Gay via use-livecode wrote: Actually, it's also in the Tools menu -> Extension manager. Interesting. The Widgets and Libraries tabs show what's in my system already. The Store tab briefly says "loading LiveCode extensions store" and then... on osx just shows me a blank panel - no content on linux, totally crashes LC after launching two more processes that have to be forceably kill-9ed. Don't try this at home. https://quality.livecode.com/show_bug.cgi?id=21573 -- Mark Wieder ahsoftw...@gmail.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: ANN: LC Documentation Cache Cleaner
On Sep 6, 2018, at 9:56 PM, J. Landman Gay via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: You have to open the LC tools palette occasionally. ;) At the top is a big plus sign. Clicking that opens a stack/window much as Sample Stacks does. A tabbed interface gives access to a number of Libraries, Widgets, and the Store (which is barely populated.) Hey, I just noticed you can hide and show individual widgets from the Widgets tab in the Extensions Manager. Click the down arrow next to the widget and it’s one of the options. I’m probably the last one to notice that. Devin Devin Asay Director Office of Digital Humanities Brigham Young University ___ 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: The Visible Hilited Line of a Datagrid
That's what I thought but apparently they are equal, and understandably, because otherwise you would not be able to reference a line that was not currently visible. but I think if you resort, the indexes change order but the lines are still the actual lines. I am figuring out a way to do this by calculating the dgHilitedLine against the dgVscroll. Bob S > On Sep 6, 2018, at 17:59 , Paul Dupuis via use-livecode > wrote: > > I don't have the dictionary handy, so check it for this, but I thought the: > > dgHilitedIndex is the record number in the array > and > dgHilitedLine was the visible line number? > > Look up dgHilitedLine vs dgHilitedIndex ___ 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: This is disturbing!
Yes. Bob S > On Sep 6, 2018, at 13:07 , Richmond Mathewson via use-livecode > wrote: > > I wonder is the reason "6" and "6." are treated as the same is because "6." > is read as "6.0"? > > Late to the party, I know . . . > > Richmond. ___ 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: This is disturbing!
There is already a string keyword. Bob S > On Sep 6, 2018, at 21:53 , Jim Lambert via use-livecode > wrote: > > >> RichardG wrote: >> Any suggestions for a new operator token to specify numeric equivalence? > > Or maybe to specify string equivalence. > >> Did anyone know that "6. " is equal to "6."??? > > string( "6. “) is not equal to string( "6.”) > > where the function string() would tell LC not to try to convert the string > into a number, but simply leave it as a literal string for comparison > purposes. > > Of course, another way to prevent LC from converting a textual number into an > actual number is to append a string to the textual number: > > whereas "6. “ = "6.” returns TRUE > "6. “ & “a” = "6.” & “a” returns FALSE. > > Jim Lambert ___ 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: This is disturbing!
Hi We had the same "problem" in Foxpro because of the Dbase legacy. Here is a partial list of comparisosn with the SET EXACT switch setting OFF ON OFF or ON "abc" = "abc" Yes Yes Yes -- 1 "ab" = "abc" No No No -- 2 "abc" = "ab" Yes No No -- 3 "abc" = "ab_" No No No -- 4 "ab" = "ab_" No Yes No -- 5 "ab_" = "ab" Yes Yes No -- 6 "" = "ab" No No No -- 7 "ab" = "" Yes NoNo -- 8 ... You get the picture the reason that 7 and 8 look weird is because (I believe) that the comparison scans the length of the operand which in this case is zero length, so the strings match up upto the zeroth character So why this list? Because without breaking any code we can have a setting - no different to itemdelimiter or numeric format etc like SET EXACT on or off and the engine could do the "right thing". But the right thing to me is not the right thing to you, it's an edge case and the programmer should know his data.. So here is the simplest way out of any pickle, and changes to the docs to explain this to knew programmers function EQ p1, p2 return (space & p1 = space & p2) end EQ On Mouseup local s1, s2 put "6." into s1 put "6. " into s2 answer "S1 = s2 is " & (s1 = s2) answer "S1 = s2 is " & EQ(s1 = s2) end Mouseup And why doesn't my Python Program work - oh "You have an extra space"!! If there ever was the most stupid design decision of ANY language that must have been indentation as part of the syntax - and the second - Case sensitivity - because I want to Use "NAME" and "name" to help me differentiate Adults from children Oh and while in Rant mode don'y get me stated on PHP ... Case sensitive variables, constants, array keys, class properties, class constants Case insensitive functions, class constructors, class methods, keywords and constructs (if, else, null, foreach, echo etc.) So count your blessings ... Regards Lagi On Fri, 7 Sep 2018 at 03:42, Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Mike Kerner wrote: > > I like the is vs = idea. > > Me too, but I'm afraid decades of code across the entire xTalk world > form a substantial enough legacy to render the change prohibitive. > > Any suggestions for a new operator token to specify numeric equivalence? > > -- > 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 > ___ 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: ANN: LC Documentation Cache Cleaner
Richard asks re the new extension store.. > When? Well its initial offering is already here, see Jacque’s posts. As for when it will offer what was promised...probably sometime after Infinite Livecode has delivered the components and examples it promised or after DataGrid 2 is complete and delivered. Not holding my breathe. James ___ 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
