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
> 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
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
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-r
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
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
:-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.
__
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 butto
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 exp
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
>
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
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
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
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 th
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
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 positio
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-liveco
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 w
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 f
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 fo
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
21 matches
Mail list logo
