Re: spotting a mouseclick in the transparent area of an image

[Paul Hibbert via use-livecode]

Ben, if you could edit the PNGs to add a 1% tone to the transparent areas 
(maybe with a batch process) this allows LC to accept the clicks within the 
image area.

The advantage of this is you could have a 1 % tone inside the area you need be 
active and completely transparent where you don’t want clicks to be active for 
example a circular button. The 1% tone should be indistinguishable from the 
transparent area and will still show the background through.

Paul


> On Mar 30, 2017, at 10:52 AM, Ben Rubinstein via use-livecode 
>  wrote:
> 
> I have a group containing a grid of square images.
> 
> Some of the images are gifs, some are pngs, and some of the latter have an 
> alpha channel with some transparent bits.
> 
> The images are all used as buttons, to control something else - the images in 
> essence are labels or icons for the buttons. The images have 3d borders to 
> make them look more button-like.
> 
> The problem is that the if the user happens to click in the transparent area 
> of an image, the target of the mouseup isn't the image but the card. But the 
> image is a button, so I want to catch mouseup anywhere in this square image.
> 
> I thought that I might be able to use 'the mousecontrol', when the target was 
> the card, to find out which image the mouse was in when; but this too takes 
> account of the transparency of the image.
> 
> I can see this is a really useful feature - but in this case I want the 
> opposite! Is there a flag somewhere, or another easy way to achieve this?
> 
> The non-easy ways I'm aware of are:
>   - hide all the images and replace them with buttons referencing the 
> images
>   - re-compositing the images to flatten the alpha channel
>   - iterating through all the images - there are many, in a scrolling 
> group - testing for the mouseloc within the rect of each
> 
> 
> Is there anything simpler than this, to treat an image as opaque for the 
> purposes of hit-testing?
> 
> TIA
> 
> Ben
> 
> 
> 
> ___
> 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: Cheesed off by 32xxx

[Curry Kenworthy via use-livecode]

Richmond say:

> The problem, such as it is, is that the Unicode specifications
> have 128 * 8703 slots for glyphs ... hence 8703 buttons.

Channeling Sensei again for fun - Does man with million chopsticks line 
them all side by side, only one layer deep? He need very big custom 
table, very expensive, no more bamboo or tree left for chopstick.


If you have 8703 buttons, must they all be lined up at once?

Again, by arranging the buttons in several groups of perhaps 800, you 
could circumvent the 32K pixel limitation as you wished to do. A little 
scrolling code creates the illusion that they are one big group, but 
none of the edges are ever more than 32K from 0,0.


I have to advocate a field or a very small set of buttons instead, much 
easier and huge advantages. We don't need thousands of buttons to 
display the Unicode tables.


But focusing just on the 32K pixel issue, which could apply to other 
situations, I think your 8703 * 23 approach should be doable! Only a 
question of organization and arrangement. To the user it would look the 
same as if it were one big group.


Best wishes,

Curry K.

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: Line numbers for soft-wrapped styled text?

[hh via use-livecode]

Alex,

a brilliant technique. It is certainly usable for other "searching"
tasks. And it simply needs for this use case a faster measurement-method
as input. We could try the selectedLoc:

The script below gets for me the exakt topLefts of the visible ones of
2 "worse case"-lines in < 1 second, with LC 9, and in LC 6 it is
three times faster, on a medium fast machine (2.5 GHz macMini).
I'm sure you can take the following quick and dirty routine again down
to at least 50% of needed time with your optimization technique.

Hermann

## Commented for occasional readers.
## You still has to use the locations for a numbers display: Use either
## one num-field per line or one for all using Alex's method of space below.

local rg=TEXT", l0, t0, b0, v0
local gpoints -- collects the toplefts of the lines

on updateNbs2
  put the millisecs into m1
  lock screen; lock messages
  put the top of fld rg into t0
  put the left of fld rg into l0
  put the bottom of fld rg into b0
  put the height of fld rg into h0
  put the selectedChunk into sc
  put the vscroll of fld rg into v0
  put the num of lines of fld rg into nL
  put visibleTextLines(nL) into tL
  put "Lines: " & tL & " of " & nL into fld "range"
  put gPoints into fld "info" -- ready to use
  -- avoid bug(?) with the field num:
  if sc is not empty then
do ("select "& (word 1 to 4 of sc) &" of fld "& rg )
  end if
  set the vscroll of fld rg to v0
  put (the millisecs-m1) & " ms" into fld "timing"
  unlock screen; unlock messages
end updateNbs2

-- returns the visible lines range and (in gPoints) the toplefts
-- n is the num of lines
function visibleTextLines n
  put the scrollbarWidth of fld rg into sw
  put the margins of fld rg into m
  put (m,m,m,m) into m -- now we have always at least 4 items
  put findTopLine(v0+t0-1+item 2 of m,1,n) into L1
  put L1-1 into L2; put v0+b0+6-item 4 of m into x
  put empty into gPoints
  -- now a simple line-after-line check could/should be made faster,
  -- its advantage: We get at the same time already the locations!
  repeat while L2 <= n
add 1 to L2
set vscroll of fld rg to v0 -- important for measuring
select before line L2 of fld rg
put item 2 of the selectedLoc into slc
put cr & (l0,slc) after gPoints -- adjust here the left
if (the vscroll of fld rg) + slc > x then
  put line 2 to -2 of gPoints into gPoints
  exit repeat
end if
  end repeat
  return L1,L2-1
end visibleTextLines

-- the simplest recursive method as base for optimization
function findTopLine x,n1,n -- x=top pixel value, n1=start, n=max
  put n1+((n-n1) div 2) into m
  set vscroll of fld rg to v0
  select before line m+1 of fld rg
  put the vscroll of fld rg + item 2 of the selectedLoc into vsl
  if vsl >= x then
set vscroll of fld rg to v0
select before line m of fld rg
put the vscroll of fld rg + item 2 of the selectedLoc into vsl
if vsl < x then return word 2 of the selectedLine
else
  if m <= n1 then return n1
  else return findTopLine(x,n1,m-1)
end if
  else
if m >= n then return n
else return findTopLine(x,m+1,n)
  end if
end findTopLine

## The field's script is again:
on textchanged
  updateNbs2
end textchanged

on scrollbardrag
  updateNbs2
end scrollbardrag
### END_OF_SCRIPT

> Alex T. wrote:
> Sure, here it is.
> 
> I couldn't resist doing some simple benchmarks, just to verify my 
> intuition. Very glad I did.
> 
> OK - here's the theory :
> 
>   we're using variations of binary search to find the lowest numbered 
> line that is visible, and then again to find the highest numbered line.
> 
> So at each stage we have an interval within which the right answer must 
> lie.
> 
> 1. Simple binary search : the next guess is the middle of the current 
> interval.
> 
> This is simple, and very consistent for the number of guesses needed: 
> the worst case is almost identical to the average/typical.
> 
> For my test case (25000 lines of heavily styled text), we need approx 14 
> guesses for the first calculaiton, and 8 for the second.
> 
> 2. Simple Newton-Raphson (linear interpolation).
> 
> This is usually better than simple binary, *if* there is a reasonable 
> correlation between the measurable values and the guessable values. In 
> this case there - the height of any chunk of lines is reasonably 
> correlated to the number of lines, though not exactly in all cases.
> 
> Usually this will take significantly fewer guesses (and in this case it 
> takes around 8 + 4 compared to the 14+8 above).
> 
> BUT - the worst case can be much, much worse :-(   Imagine a field with 
> 1000 lines - the first 500 are in 5-point text, and the other 500 are in 
> 1000 point text, scrolled forward by 400 lines; this makes our guessing 
> VERY poor, and will take up to 200 or more guesses.
> 
> 3. Use a mix of linear interpolation and binary search. I tried simply 
> alternating them - one calculated guess, then one 'average' guess, then 
> another calculated one, 
> 
> This 

Re: tsNet docs?

[Richard Gaskin via use-livecode]

Charles Warwick wrote:

> Firstly my apologies on the lack of documentation, it is definitely
> on my todo list and I am working on some Livecode lessons for tsNet
> at the moment.

Looking forward to them - thanks.


> I have just double checked that stack and noticed that the call to
> tsNetUploadSync is using the wrong syntax (it changed at one point)
> which could be causing you issues.
>
> An updated version is now available at that same URL with the
> corrected the syntax for that call and another button so that there
> are now examples for both uploading via SFTP and FTPS.
>
> These should work correctly on Indy and I have confirmed that here.

Thanks.  I'm no longer getting the license error with either FTPS or 
SFTP, and indeed I was able to upload a file with FTPS so that much is good.


With SFTP, however, I'm getting weird results, something I've never seen 
before, like LC is in some sort of semi-hung state.


I fill in the relevant fields, click "SFTP Upload Example", but then I 
don't get anything in the Results field and as long as I care to wait my 
CPU monitor shows LC churning up about 23%, but there's no visible 
indication that anything's happening.


Hoping to explore the script to guess what might be happening, I found I 
could switch tool modes and right-click on the button, but when I select 
"Edit Script" in the popup button nothing happens.


At that point some things are unresponsive, others eventually become 
responsive after long delays, and -- weirdest of all - after I quit C 
it's still shown as a process in my process list.


This is on Ubuntu 14.04, with LC v9 DP6.

Any other info I can provide?  Should I file a formal bug report on this?

--
 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: Unicode Reference stack

[Bob Sneidar via use-livecode]

Nicely done Richmond!

Bob S


> On Apr 1, 2017, at 12:36 , Richmond Mathewson via use-livecode 
>  wrote:
> 
> Things just got better!
> 
> On 3/31/17 10:11 pm, Richmond Mathewson wrote:
>> Here: http://forums.livecode.com/viewtopic.php?f=26=29069
>> 
>> 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: Cheesed off by 32xxx

[Mike Bonner via use-livecode]

Got bored. Heres a version using a datagrid form so you can keep that
buttony look.
https://www.dropbox.com/s/p8xlv0zoyeb34za/CHAR%20REFDG.livecode?dl=0

On Sun, Apr 2, 2017 at 12:25 PM, Jim Lambert via use-livecode <
use-livecode@lists.runrev.com> wrote:

> A little fancier.
>
> on mouseup
> put token 2 of the value of the clickline into MAGIC
> put baseConvert(MAGIC, 16, 10) into WAL
> put 0 into KOUNT
> lock screen for visual effect  in rect (the rect of grp "BOXES")
> repeat for 128 times
> set the label of btn ("B" & KOUNT) to
> numToCodepoint(KOUNT+WAL)
> add 1 to KOUNT
> end repeat
> put the short name of me into fld "RANGE"
> unlock screen with visual effect  "scroll right" very fast
> end mouseup
>
>
> on populateMe
> put "" into me
> lock screen
> put the number of buttons of grp UNIlist into nBtns
> repeat with x = 1 to nBtns
> put the short name of btn x of grp UNIlist into line
> (nBtns +1) - x of me
> end repeat
> end populateMe
>
>
> 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
>
___
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: Cheesed off by 32xxx

[Jim Lambert via use-livecode]

A little fancier.

on mouseup
put token 2 of the value of the clickline into MAGIC
put baseConvert(MAGIC, 16, 10) into WAL
put 0 into KOUNT
lock screen for visual effect  in rect (the rect of grp "BOXES")
repeat for 128 times
set the label of btn ("B" & KOUNT) to numToCodepoint(KOUNT+WAL)
add 1 to KOUNT
end repeat
put the short name of me into fld "RANGE"
unlock screen with visual effect  "scroll right" very fast
end mouseup


on populateMe
put "" into me
lock screen
put the number of buttons of grp UNIlist into nBtns
repeat with x = 1 to nBtns
put the short name of btn x of grp UNIlist into line (nBtns +1) 
- x of me
end repeat
end populateMe


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: Cheesed off by 32xxx

[Jim Lambert via use-livecode]

Richmond,

You could give this a try.
Drag a scrolling list field onto the card. 
Name it ‘UNIlist’.
This will eventually replace for group ‘UNIlist', which contains your 
problematic number of buttons.
Put this in the script of the scrolling list field ‘UNIlist'
on mouseup

put token 2 of the value of the clickline into MAGIC

put baseConvert(MAGIC, 16, 10) into WAL

put 0 into KOUNT

lock screen

repeat for 128 times

set the label of btn ("B" & KOUNT) to numToCodepoint(KOUNT+WAL)

add 1 to KOUNT

end repeat

put the short name of me into fld "RANGE"

end mouseup


on populateMe

put "" into me

lock screen
put the number of buttons of grp UNIlist into nBtns

repeat with x = 1 to nBtns

put the short name of btn x of grp UNIlist into line (nBtns +1) 
- x of me

end repeat

end populateMe


Now execute "send populateMe to the field UNIlist” in the message box

Now click any line of the scrolling list field ‘UNIlist’.

The scrollingligst field should be able to hold considerably more than 1400 
lines.
Result: de-cheesement!

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: Cheesed off by 32xxx

[Richmond Mathewson via use-livecode]

I'm interested and will have a look at it after supper.

Thanks, Richmond.

On 4/2/17 8:01 pm, Mike Bonner via use-livecode wrote:

Just for fun, I did as others have said and converted the stack to use a
field.  Since each button used the same exact script (as far as I could
tell, too many to go through individually) it was easy to modify it to use
the selectedtext rather than the label of the clicked button.  TO get the
fonts for the list I looped through buttons looking for all that contained
hex and grabbed the labels, sorted the resulting list so that it matched
your original arrangement, and voila'.  Had to adjust the preopencard
handler to account for the changes. I missed something. If you're
interested, the adjusted stack is here.
https://www.dropbox.com/s/bn5ihcosxd6vj8f/CHAR%20REF.livecode?dl=0

On Sun, Apr 2, 2017 at 10:01 AM, Curry Kenworthy via use-livecode <
use-livecode@lists.runrev.com> wrote:


Howdy Richmond,

Wise man do many things with few buttons. Elite master use single field.
That is the true path to LC enlightenment, avoiding all unnecessary sorrows
in coding and interface.

Having said that, you specifically asked for a way to circumvent the 32k
pixel limitation for positioning. That should be possible. (And doubly
worth mentioning because it could apply to other situations with fewer, but
larger, controls.)

If you split the 1600 controls into two groups rather than one, and add a
little special code to swap them smoothly while scrolling

Thus you would never need 8703 buttons on top of each other. However, the
same is true of the 1600 or the 800. It's a fun exercise and a great test
of LC's limits and performance, but a different approach will be more
efficient.

Very nice topic for an app, I love Unicode tables! Very handy.

Best wishes,

Curry K.

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


___
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: Cheesed off by 32xxx

[Richmond Mathewson via use-livecode]

On 4/2/17 7:01 pm, Curry Kenworthy via use-livecode wrote:


Howdy Richmond,

Wise man do many things with few buttons.


Yup: only one problem there . . . I prefer zippers!


Elite master use single field.


Difficult when you have to make sure the bull doesn't get in with the cows.

That is the true path to LC enlightenment, avoiding all unnecessary 
sorrows in coding and interface.


Yes, Master Sensei, I bow so low my nose scrapes the underside of my iMac.



Having said that, you specifically asked for a way to circumvent the 
32k pixel limitation for positioning. That should be possible. (And 
doubly worth mentioning because it could apply to other situations 
with fewer, but larger, controls.)


If you split the 1600 controls into two groups rather than one, and 
add a little special code to swap them smoothly while scrolling


Thus you would never need 8703 buttons on top of each other.


The problem, such as it is, is that the Unicode specifications have 128 
* 8703 slots for glyphs (= a big number my mind cannot cope with)
and the display in my "CHAR REF" stack is set up to cope with 128 glyphs 
a go: hence 8703 buttons.


Of course I could be racist and leave out the Chinese ideograph slots (= 
about 70%) . . .


However, the same is true of the 1600 or the 800. It's a fun exercise 
and a great test of LC's limits


I wonder if that limit is "cast in stone" or the Livecode people could 
expand it?



and performance, but a different approach will be more efficient.


Probably, but after my first beige G3 Mac (1998) everything has always 
gone quite fast enough for me.


Very nice topic for an app, I love Unicode tables! Very handy.


Indeed.



Best wishes,

Curry K.


Best, 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: Cheesed off by 32xxx

[Mike Bonner via use-livecode]

Just for fun, I did as others have said and converted the stack to use a
field.  Since each button used the same exact script (as far as I could
tell, too many to go through individually) it was easy to modify it to use
the selectedtext rather than the label of the clicked button.  TO get the
fonts for the list I looped through buttons looking for all that contained
hex and grabbed the labels, sorted the resulting list so that it matched
your original arrangement, and voila'.  Had to adjust the preopencard
handler to account for the changes. I missed something. If you're
interested, the adjusted stack is here.
https://www.dropbox.com/s/bn5ihcosxd6vj8f/CHAR%20REF.livecode?dl=0

On Sun, Apr 2, 2017 at 10:01 AM, Curry Kenworthy via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> Howdy Richmond,
>
> Wise man do many things with few buttons. Elite master use single field.
> That is the true path to LC enlightenment, avoiding all unnecessary sorrows
> in coding and interface.
>
> Having said that, you specifically asked for a way to circumvent the 32k
> pixel limitation for positioning. That should be possible. (And doubly
> worth mentioning because it could apply to other situations with fewer, but
> larger, controls.)
>
> If you split the 1600 controls into two groups rather than one, and add a
> little special code to swap them smoothly while scrolling
>
> Thus you would never need 8703 buttons on top of each other. However, the
> same is true of the 1600 or the 800. It's a fun exercise and a great test
> of LC's limits and performance, but a different approach will be more
> efficient.
>
> Very nice topic for an app, I love Unicode tables! Very handy.
>
> Best wishes,
>
> Curry K.
>
> 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
>
___
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: Cheesed off by 32xxx

[Curry Kenworthy via use-livecode]

Howdy Richmond,

Wise man do many things with few buttons. Elite master use single field. 
That is the true path to LC enlightenment, avoiding all unnecessary 
sorrows in coding and interface.


Having said that, you specifically asked for a way to circumvent the 32k 
pixel limitation for positioning. That should be possible. (And doubly 
worth mentioning because it could apply to other situations with fewer, 
but larger, controls.)


If you split the 1600 controls into two groups rather than one, and add 
a little special code to swap them smoothly while scrolling


Thus you would never need 8703 buttons on top of each other. However, 
the same is true of the 1600 or the 800. It's a fun exercise and a great 
test of LC's limits and performance, but a different approach will be 
more efficient.


Very nice topic for an app, I love Unicode tables! Very handy.

Best wishes,

Curry K.

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: Line numbers for soft-wrapped styled text?

[Alex Tweedly via use-livecode]

Sure, here it is.

I couldn't resist doing some simple benchmarks, just to verify my 
intuition. Very glad I did.


OK - here's the theory :

 we're using variations of binary search to find the lowest numbered 
line that is visible, and then again to find the highest numbered line.


So at each stage we have an interval within which the right answer must 
lie.


1. Simple binary search : the next guess is the middle of the current 
interval.


This is simple, and very consistent for the number of guesses needed: 
the worst case is almost identical to the average/typical.


For my test case (25000 lines of heavily styled text), we need approx 14 
guesses for the first calculaiton, and 8 for the second.


2. Simple Newton-Raphson (linear interpolation).

This is usually better than simple binary, *if* there is a reasonable 
correlation between the measurable values and the guessable values. In 
this case there - the height of any chunk of lines is reasonably 
correlated to the number of lines, though not exactly in all cases.


Usually this will take significantly fewer guesses (and in this case it 
takes around 8 + 4 compared to the 14+8 above).


BUT - the worst case can be much, much worse :-(   Imagine a field with 
1000 lines - the first 500 are in 5-point text, and the other 500 are in 
1000 point text, scrolled forward by 400 lines; this makes our guessing 
VERY poor, and will take up to 200 or more guesses.


3. Use a mix of linear interpolation and binary search. I tried simply 
alternating them - one calculated guess, then one 'average' guess, then 
another calculated one, 


This should significantly limit the worst case - but makes the average 
somewhat worse.


4. Use linear interpolation - but disallow very small (or very large) 
estimates.


This again limits the worst case (not quite so well), and makes the 
average only slightly worse.



I tried each of these strategies on a range of scroll positions in my 
test case field. Results were


(1) Binary   6283

(2) N-R  3757

(3) N-R/binary 4200

(4) N-R limited 3782


So - the script below does (4) above - linear interpolation, with the 
very small or very large percentage guesses disallowed. But, I've left 
in the code (commented out) to also do alternating binary guesses, so it 
can be easily used if your use case is very sensitive to extreme examples.


Note - this only uses the accurate height of a chunk function once it 
has almost determined its answer - up until then, it only needs 
approximate results to make the next guess, so no need for the extra 
work of doing the pixel-accurate calculation.


function visibleTextLines pT
   local vs, sw, m, t, b, L1, L2
   local t1, t2, t3  -- timing
   lock screen; lock messages
   put the vscroll of fld pT into vs
   put the scrollbarWidth of fld pT into sw
   put the margins of fld pT into m
   put (m,m,m,m) into m -- now we have always at least 4 items
   -- value of pixel within the field where top line will be
   put   (item 2 of m) + vs into t
   -- value of pixel within the field where bottom line will be
   put  - (item 4 of m)  + vs + the effective height of fld pT into b
   if the hscrollbar of fld pT then subtract sw from b

   put the millisecs into t1   -- timing
   put findTopLine(pT, t-5) into L1
   put the millisecs into t2   -- timing
   put findBottomLine(pT, b+5, L1) into L2
   put the millisecs into t3   -- timing
   --put "times" && t2-t1 && t3-t2  after fld "Flog" -- timing
   return (L1,L2)
end visibleTextLines


function findTopLine pFName, pPixel
   -- for fld 'pFName', find the lowest numbered line which will be at 
or beyond pPixel


   local tBelow, tAbove, tGuess, tTotal
   local tTarget

   put 1 into tBelow
   put 0 into tHBelow

   put the number of lines in fld pFName into tAbove
   put the formattedheight of fld pFName into tHAbove

   put pPixel into tTarget

   -- we need to find the first line whose formattedheight is >= tTarget
   local tD, tIteration
   repeat with tIteration = 1 to 1000
  if tAbove = tBelow+1 then exit repeat
  --   if tIteration mod 2 = 0 then  -- alternate between 
lienar interpolation and simple binary halving

  --  put 0.5 into tD
  --   else
  put (tTarget-tHBelow) / (tHAbove-tHBelow) into tD
  --   end if

  -- limit very small or large [percentages
  if td < 0.05 then put 0.05 into tD
  if td > 0.95 then put 0.95 into tD

  put tBelow + trunc( (tAbove-tBelow) * tD) into tGuess
  if tGuess = tBelow then add 1 to tGuess
  --   put tGuess && tBelow && tAbove  after fld "Flog"

  put the formattedheight of line 1 to tGuess of fld pFName into tt 
-- NB may be inaccurate !!

  if tt > tTarget then
 put tGuess into tAbove
 put tt into tHAbove
  else
 put tGuess into tBelow
 put tt into tHBelow
  end if
   end repeat
   -- now deal with the possible inaccuracy
   repeat 2 times -- should be no more than 1 !?

Re: codePointToNum

[Kay C Lan via use-livecode]

On Sat, Apr 1, 2017 at 4:11 AM, Richmond Mathewson via use-livecode
 wrote:

> put baseConvert(codePointToNum("&"), 10, 16)
>
> BUT it go "all stuffy" about the codePointToum, so I did this:
>
> put codePointToNum("&") into NUMM
> put baseConvert(NUMM, 10, 16)
>

On my Mac 10.11.6 using LC 9.0.0 dp4 both of those code snippets
produce '26' in an egalitarian manner.

There should be no reason why:

 put baseConvert(codePointToNum("&"), 10, 16)

should make your computer "all stuffy". If it is then there is a bug to report.

___
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: within and scaleFactor

[Roger Eller via use-livecode]

Also the content of option menus remain at 1X scale even though everything
else has increased in size.  #thatsabug

~Roger

On Apr 1, 2017 3:17 PM, "Dan Friedman via use-livecode" <
use-livecode@lists.runrev.com> wrote:

> I call this a bug, would you?
>
> If the scaleFactor of stack “myStack” is set to 2, then within(stack
> “myStack”,the screenMouseLoc) only returns true if the mouse is within the
> rect of stack “myStack” when it’s scaleFactor is set to 1.  Hope I
> explained that logically.
>
> Mac 10.12.2, LC 9.0.0 dp 6.   Worked correctly in LC 7.
>
> -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
___
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: Cheesed off by 32xxx

[panagiotis merakos via use-livecode]

Hi Richmond,

I think what you are trying to achieve is described in this report:

http://quality.livecode.com/show_bug.cgi?id=18704

As suggested, it is probably better to use a DataGrid in this case.

Best,
Panos
--

On Sun, Apr 2, 2017 at 8:14 AM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:

> One of the ways about knowing what I'm trying to accomplish is to download
> the stack and have a look at it.
>
> Richmond.
>
>
> On 4/2/17 1:59 am, Scott Rossi via use-livecode wrote:
>
>> Without knowing exactly what you're trying to accomplish, one way is to
>> display only a few rows of buttons beyond what will fit comfortably on a
>> screen, and when scrolling takes place, "recycle" the rows around to the
>> end (or beginning) with new glyphs applied.
>>
>> Assuming all the characters are from a single font and you're trying to
>> display glyphs in an organized fashion,  a better way might be to display
>> all the glyphs in a field with extra column and row spacing to essentially
>> form a grid.   This is how I display glyphs from icon fonts, which is more
>> efficient than using thousands of controls on a card.
>>
>> Regards,
>>
>> Scott Rossi
>> Creative Director
>> Tactile Media UX/UI Design
>>
>> On Apr 1, 2017, at 3:07 PM, Richmond Mathewson via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>>
>>> What a nuisance:
>>>
>>> There I was, merrily churning through the button titles for my Unicode
>>> Reference thing
>>> [ http://forums.livecode.com/viewtopic.php?f=26=29069 ] which needed
>>> at least 1600 buttons
>>> that were 23 pixels deep layered underneath each other.
>>>
>>> What happens?
>>>
>>> At the "Magic Number" of 32xxx I get a "this is not a number" message.
>>>
>>> As a result I ended up restricted to 1400 buttons.
>>>
>>> This is very bad as the Unicode glyph tables are many, and in an ideal
>>> world
>>> I'd like 8703 buttons. But 8703 * 23 = 200169
>>>
>>> That would involve groupig a "stack" of buttons that was 200169 pixels
>>> high.
>>>
>>> Would be grateful if anyone knows a way to circumvent the limitation.
>>>
>>> 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
>>>
>>
>> ___
>> 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: Cheesed off by 32xxx

[Richmond Mathewson via use-livecode]

One of the ways about knowing what I'm trying to accomplish is to 
download the stack and have a look at it.


Richmond.

On 4/2/17 1:59 am, Scott Rossi via use-livecode wrote:

Without knowing exactly what you're trying to accomplish, one way is to display only a 
few rows of buttons beyond what will fit comfortably on a screen, and when scrolling 
takes place, "recycle" the rows around to the end (or beginning) with new 
glyphs applied.

Assuming all the characters are from a single font and you're trying to display 
glyphs in an organized fashion,  a better way might be to display all the 
glyphs in a field with extra column and row spacing to essentially form a grid. 
  This is how I display glyphs from icon fonts, which is more efficient than 
using thousands of controls on a card.

Regards,

Scott Rossi
Creative Director
Tactile Media UX/UI Design


On Apr 1, 2017, at 3:07 PM, Richmond Mathewson via use-livecode 
 wrote:

What a nuisance:

There I was, merrily churning through the button titles for my Unicode 
Reference thing
[ http://forums.livecode.com/viewtopic.php?f=26=29069 ] which needed at least 
1600 buttons
that were 23 pixels deep layered underneath each other.

What happens?

At the "Magic Number" of 32xxx I get a "this is not a number" message.

As a result I ended up restricted to 1400 buttons.

This is very bad as the Unicode glyph tables are many, and in an ideal world
I'd like 8703 buttons. But 8703 * 23 = 200169

That would involve groupig a "stack" of buttons that was 200169 pixels high.

Would be grateful if anyone knows a way to circumvent the limitation.

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


___
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: tsNet docs?

[Charles Warwick via use-livecode]

Hi Richard,

Firstly my apologies on the lack of documentation, it is definitely on 
my todo list and I am working on some Livecode lessons for tsNet at the 
moment.


I have just double checked that stack and noticed that the call to 
tsNetUploadSync is using the wrong syntax (it changed at one point) 
which could be causing you issues.


An updated version is now available at that same URL with the corrected 
the syntax for that call and another button so that there are now 
examples for both uploading via SFTP and FTPS.


These should work correctly on Indy and I have confirmed that here.  Are 
you by any chance trying to use the tsNetUploadFileSync command instead 
of tsNetUploadSync?


If so, these are only supported in the business edition if you are 
trying to use SFTP.


Regards,

Charles


On 2/04/2017 10:54 AM, Richard Gaskin via use-livecode wrote:
I finally got around to playing with tsNet, but I can't find docs, 
just sparse Dict entries.


I'd like to test uploading a file via SFTP and also FTPS, synchronous 
preferred in this case.


After hunting around via Google I manage to turn up this stack from a 
blog post:
 



But when I run a modified version of the "SFTP Upload example" button 
I get an error complaining about it being unlicensed.


I'm using Indy, and I believe synchonrous upload vis SFTP is supported 
with Indy, no?


Anyone here have a concise example of synchronous uploading via tsNet?




___
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