Cheesed off by 32xxx

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Cheesed off by 32xxx

Monte Goulding 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&t=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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding 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&t=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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding via use-livecode
In reply to this post by Monte Goulding 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 <[hidden email]> 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&t=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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding 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 <[hidden email]> 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&t=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
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding 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 <
[hidden email]> 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 <
>>> [hidden email]> 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&t=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
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding via use-livecode
In reply to this post by Monte Goulding 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding 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 <
[hidden email]> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding via use-livecode
In reply to this post by Monte Goulding 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding via use-livecode
In reply to this post by Monte Goulding 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 <
> [hidden email]> 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
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding via use-livecode
In reply to this post by Monte Goulding 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding via use-livecode
In reply to this post by Monte Goulding 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding 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 <
[hidden email]> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding via use-livecode
In reply to this post by Monte Goulding 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding via use-livecode
In reply to this post by Monte Goulding 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding via use-livecode
In reply to this post by Monte Goulding via use-livecode
:-D

> On Apr 2, 2017, at 18:23 , Curry Kenworthy via use-livecode <[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding via use-livecode
In reply to this post by Monte Goulding via use-livecode
The short version: Datagrid.... GOOD!

Bob S


> On Apr 2, 2017, at 23:58 , Mark Waddingham via use-livecode <[hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding 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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding 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 <
[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding via use-livecode
In reply to this post by Monte Goulding 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cheesed off by 32xxx

Monte Goulding via use-livecode
In reply to this post by Monte Goulding 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12
Loading...