Brian Milby wrote:
> On Fri, Sep 7, 2018 at 11:45 PM Richard Gaskin wrote:
>> ...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?
>>
Hi,
Can LiveCode communicate with Bluetooth devices?
Is there a way that this can be done?
A few Bluetooth devices with bad interface issues could be rewritten
innLiveCode but I am clueless how that might occur.
Mark Rauterkus
--
--
Ta.
Mark Rauterkus m...@rauterkus.com
Executive Dir
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 a
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 altere
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 o
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 m
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
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'
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 do
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 shoul
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
> 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 str
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 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
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
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, an
> 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.
funct
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 item
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
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
>> scro
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
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 component
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 show
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 nu
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
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-
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 equ
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_"
28 matches
Mail list logo
