Re: Cheesed off by 32xxx

[Dr. Hawkins via use-livecode]

On Mon, Apr 3, 2017 at 10:06 AM, Stephen Barncard via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Sometimes an illusion of an illusion in the illusion. So that's my
> allusion.
>

elusively alluded alliteration . . .


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Cheesed off by 32xxx

[Jim Lambert via use-livecode]

> RichardG wrote:
> 
> the memory and CPU requirements for working with tens of thousands of objects 
> can be onerous

Not to mention how onerous it would be for the poor end user to work with tens 
of thousands of objects!

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]

Thanks for such an informative posting.

On 4/3/17 9:58 am, Mark Waddingham via use-livecode wrote:

On 2017-04-02 19:07, Richmond Mathewson via use-livecode wrote:

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%) . . .


You'd probably be okay with 8703 buttons (were there not a co-ordinate 
magnitude limit), but certainly not with 128*8703 buttons.


Oh: I am perfectly capable of pumping out 8703 buttons, that is NOT the 
problem.


The problem is to have them placed sequentially one above the other in a 
"monster list" grouped into a 700 pixel high group with
a vertical scrollbar: even that, as such, is not the problem: the 
problem is thatthere is no way I can stack those buttons up

vertically prior to grouping them.

128*8703 not necessary at all (quite apart from the fact that I'd be 
even more out of my box

than I am already to contemplate that).


To give some context...

Each button takes up at least 128 bytes in memory, so:

  8703 buttons is about 1.4Mb - which isn't too bad

  8703*128 buttons would be about 150Mb - which is substantially more

Admittedly, neither of these will 'break the bank' in terms of memory 
availability, even on machines of a G3 Mac vintage, however just 
storing the representation of such things in memory is not the only 
issue. The engine has to do things like:


  - render all the controls on the card

  - perform hit testing when the user clicks or interacts with the card

  - search for controls when you reference them in script

Rendering requires a linear back to front scan of each control, 
painting each one which is within the visible rect of the window the 
card sits in. This means that if you have 8703*128 buttons it will 
need to perform that many steps to render. Additionally, whenever a 
small amount changes, it needs to do this again - as any one control 
*could* have been moved or intersect with the area which has changed 
(and thus require rendering).


Hit testing is similar, although the process is from front to back, 
and stops as soon as a control says it is the target of the mouse / 
user interaction event.


The third case, is the killer though. Looking up a control by name or 
by later requires (on average) number of controls on card / 2 steps to 
perform. If you use the (short) id, then there is a per-stack cache 
which makes the lookup take 1 step if it has been looked up before but 
the normal number of steps if it has not.


In general, we'd never advise using so many controls on a single card 
- and a data-oriented approach which is what others have suggested is 
generally the best approach in this case. i.e. Update the content of a 
small set of buttons as the user browses through the list.



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


Currently engine controls are limited to 16-bit quantities for 
co-ordinates - which means a range of -32768 to 32768. The underlying 
rendering library we use (libgraphics), however, uses floats (32-bit 
real numbers which given an integer range up to around 2^24). So, 
updating the engine to use floats or similar in its co-ordinates for 
controls is certainly possible, just not a task we've undertaken yet.


Warmest Regards,

Mark.



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

[Stephen Barncard via use-livecode]

20,000 "LIKES" - Richard!
You have expressed so well my feelings that I couldn't find the words for.

[rant]
The power we have in this tool [Livecode] cannot be overstated.
We have to remember it's "just" a tool-kit and there's a lot of stuff
that's already pre-assembled. And the rest can be hand-rolled given enough
desire. But we're also expected to put in some work to make it so.
And the fact that it ALL is an illusion cannot be ignored.  (don't take my
word for it, ask your local guru)
Sometimes an illusion of an illusion in the illusion. So that's my
allusion.

software at the speed of thought, indeed.

[/rant]


On Mon, Apr 3, 2017 at 9:47 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> One of the beautiful things about making GUIs in LiveCode is that we
> generally get a very satisfying and immediate sense of physicality with the
> controls we're working with:  we envision the user interface, drag out
> controls to match that vision, and we have a one-to-one correspondence
> between what we're doing as developers and what the end-user is working
> with.




--
Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
___
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

[Richard Gaskin via use-livecode]

One of the beautiful things about making GUIs in LiveCode is that we 
generally get a very satisfying and immediate sense of physicality with 
the controls we're working with:  we envision the user interface, drag 
out controls to match that vision, and we have a one-to-one 
correspondence between what we're doing as developers and what the 
end-user is working with.


Most of the time this physicality lends itself to an uncommonly 
productive workflow.  I was talking about this with Trevor the other 
day, and we both agreed that the direct manipulation of controls in a 
"live" environment, coupled with a language that includes GUI controls 
as first-class citizens, is a big part of why we continue to rely on and 
enjoy LiveCode.


But from time to time, we find particularly ambitious GUI designs that 
become problematic within this paradigm.  Not impossible, but requiring 
us to abandon the comfortable sense of physicality to consider more 
traditional solutions.


As Mark Waddingham pointed out, the memory and CPU requirements for 
working with tens of thousands of objects can be onerous, in some cases 
perhaps prohibitively so.


That's part of the reason why most of the world solves GUI problems 
through radically different means than LC does.


LiveCode does such a good job of maintaining the illusion that GUIs are 
physical objects that we often take it for granted.  But in lower-level 
tools, you're required to be constantly aware that all of that is just 
an illusion - the structs, the buffering, the hit-testing, it's all 
abstraction that only appears physical at the very end of a very complex 
set of processes.


In lower-level languages, most of the time if it ain't on screen it 
ain't instantiated.  They don't even bother.  No need - no one can see 
it anyway.  They maintain just enough info to know when a control needs 
to be instantiated, and then do so only when it will be visible in the 
window.


The DataGrid is a good example of a middle path between the abstraction 
of lower-level languages and the physicality of LC controls:


You can have any number of rows in a DG, but truth be told the only ones 
that actually exist are the ones you're looking at.


Trevor has made very smart of use of fluid scrollBarDrag message to 
populate the visible portion of the group with the controls relevant for 
that scroll position.  Everything out of view doesn't really exist, at 
least not in terms of GUI controls.


It's a non-trivial task to effectively virtualize large numbers of rows 
and instantiate only what's visible on the fly.  He's done an excellent 
job of that.


In addition to being a very valuable part of the LC toolkit, the DG is 
also a reminder that with a little effort we can solve even big problems 
in LC, even though some of the bigger ones require us to set aside the 
perceived physicality and think about things in a more traditional 
computer science way.


I've found, as Mark confirms, that the coordinate space in LC is limited 
to about 32765 px.


Given the power of computers and the ease of using LC, we might 
sometimes see that as a constraining limitation.


But think about it:  at 96dpi that's just under 28 feet on a side - far 
larger than any monitor you can buy, which means far larger than 
anything any user could possibly see.


When we need to work in unusually large spaces, it becomes time to think 
in unusual ways.


By paging rendered elements, as the DG does, we can handle nearly any 
size of coordinate space.


It requires more work to think through a solution that makes sense for 
the design at hand, but just about anything you can imagine is doable, 
even if the worst that happens is that we have to think about solutions 
using methods similar to how the rest of the world has to deal with them.


In the case of the task at hand here in this thread, the solution is 
even simpler:  the DG already provides one way to virtualize large 
numbers of controls for us with minimal effort to use, and it may be 
possible to take advantage of the flexibility of LC fields, with their 
excelling buffering, to do that as well.


But even the in a worst-case outcome, where we'd need to figure out a 
paging mechanism from scratch. I wager that even though it requires more 
effort than just laying out tens of thousand of controls, it can be done 
in LC far more productively than one could do in just about any other 
GUI toolkit.


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

[Bob Sneidar via use-livecode]

The short version: Datagrid GOOD!

Bob S


> On Apr 2, 2017, at 23:58 , Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2017-04-02 19:07, Richmond Mathewson via use-livecode wrote:
>> 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%) . . .
> 
> You'd probably be okay with 8703 buttons (were there not a co-ordinate 
> magnitude limit), but certainly not with 128*8703 buttons.
> 
> To give some context...
> 
> Each button takes up at least 128 bytes in memory, so:
> 
>  8703 buttons is about 1.4Mb - which isn't too bad
> 
>  8703*128 buttons would be about 150Mb - which is substantially more
> 
> Admittedly, neither of these will 'break the bank' in terms of memory 
> availability, even on machines of a G3 Mac vintage, however just storing the 
> representation of such things in memory is not the only issue. The engine has 
> to do things like:
> 
>  - render all the controls on the card
> 
>  - perform hit testing when the user clicks or interacts with the card
> 
>  - search for controls when you reference them in script
> 
> Rendering requires a linear back to front scan of each control, painting each 
> one which is within the visible rect of the window the card sits in. This 
> means that if you have 8703*128 buttons it will need to perform that many 
> steps to render. Additionally, whenever a small amount changes, it needs to 
> do this again - as any one control *could* have been moved or intersect with 
> the area which has changed (and thus require rendering).
> 
> Hit testing is similar, although the process is from front to back, and stops 
> as soon as a control says it is the target of the mouse / user interaction 
> event.
> 
> The third case, is the killer though. Looking up a control by name or by 
> later requires (on average) number of controls on card / 2 steps to perform. 
> If you use the (short) id, then there is a per-stack cache which makes the 
> lookup take 1 step if it has been looked up before but the normal number of 
> steps if it has not.
> 
> In general, we'd never advise using so many controls on a single card - and a 
> data-oriented approach which is what others have suggested is generally the 
> best approach in this case. i.e. Update the content of a small set of buttons 
> as the user browses through the list.
> 
>> I wonder if that limit is "cast in stone" or the Livecode people could
>> expand it?
> 
> Currently engine controls are limited to 16-bit quantities for co-ordinates - 
> which means a range of -32768 to 32768. The underlying rendering library we 
> use (libgraphics), however, uses floats (32-bit real numbers which given an 
> integer range up to around 2^24). So, updating the engine to use floats or 
> similar in its co-ordinates for controls is certainly possible, just not a 
> task we've undertaken yet.
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps


___
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

[Bob Sneidar via use-livecode]

:-D

> On Apr 2, 2017, at 18:23 , Curry Kenworthy via use-livecode 
>  wrote:
> 
> 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.


___
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

[Mark Waddingham via use-livecode]

On 2017-04-02 19:07, Richmond Mathewson via use-livecode wrote:

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%) . . .


You'd probably be okay with 8703 buttons (were there not a co-ordinate 
magnitude limit), but certainly not with 128*8703 buttons.


To give some context...

Each button takes up at least 128 bytes in memory, so:

  8703 buttons is about 1.4Mb - which isn't too bad

  8703*128 buttons would be about 150Mb - which is substantially more

Admittedly, neither of these will 'break the bank' in terms of memory 
availability, even on machines of a G3 Mac vintage, however just storing 
the representation of such things in memory is not the only issue. The 
engine has to do things like:


  - render all the controls on the card

  - perform hit testing when the user clicks or interacts with the card

  - search for controls when you reference them in script

Rendering requires a linear back to front scan of each control, painting 
each one which is within the visible rect of the window the card sits 
in. This means that if you have 8703*128 buttons it will need to perform 
that many steps to render. Additionally, whenever a small amount 
changes, it needs to do this again - as any one control *could* have 
been moved or intersect with the area which has changed (and thus 
require rendering).


Hit testing is similar, although the process is from front to back, and 
stops as soon as a control says it is the target of the mouse / user 
interaction event.


The third case, is the killer though. Looking up a control by name or by 
later requires (on average) number of controls on card / 2 steps to 
perform. If you use the (short) id, then there is a per-stack cache 
which makes the lookup take 1 step if it has been looked up before but 
the normal number of steps if it has not.


In general, we'd never advise using so many controls on a single card - 
and a data-oriented approach which is what others have suggested is 
generally the best approach in this case. i.e. Update the content of a 
small set of buttons as the user browses through the list.



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


Currently engine controls are limited to 16-bit quantities for 
co-ordinates - which means a range of -32768 to 32768. The underlying 
rendering library we use (libgraphics), however, uses floats (32-bit 
real numbers which given an integer range up to around 2^24). So, 
updating the engine to use floats or similar in its co-ordinates for 
controls is certainly possible, just not a task we've undertaken yet.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

[Scott Rossi via use-livecode]

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

Re: Cheesed off by 32xxx

[Alex Tweedly via use-livecode]

I'd create maybe 200 buttons, and change their labels, positions and 
meanings whenever the vscroll of the menu changes.


Something (very vaguely) like


on scrollHasChanged

  put the vScroll of grp "sectionMenu"  into temp

  put temp div 23 into startLine

  repeat with i = 1 to 200

put format("B%03i", i) into tName

 set the top of button tName to startLine + 23*i

set the label of button tName to line startLine + i of gAllMyLabels

 

  end repeat

end scrollHasChanged


-- Alex

On 01/04/2017 23:07, 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

Cheesed off by 32xxx

[Richmond Mathewson via use-livecode]

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