World: r3wp

ok.  I think I understand that.  So here's my new code, which doesn't 
work.
random/seed now

;--include the binary card data
do %cards.r

the-tableau: layout [
	size 320x480 backdrop 0.170.0
	style tabstyle image 80x100 teal
	style holdplace box 80x100 coal
	across
	at 30x20 tc1: tabstyle
	tc2: tabstyle 
	tc3: tabstyle return
	at 30x130 tc4: tabstyle
	tc100: holdplace
	tc5: tabstyle return
	at 30x240 tc6: tabstyle
	tc200: holdplace
	tc7: tabstyle return
	at 30x350 tc8: tabstyle
	tc9: tabstyle
	tc10: tabstyle
]

lc: copy []
lc: [tc1 tc2 tc3 tc4 tc5 tc6 tc7 tc8 tc9 tc10]

deck-cards: copy [] 	; The deck holds all of the cards from the binary 
file
deck-cards-num: copy []
deck-cards-color: copy []

foreach [card label num color pos] cards [
	
	dimg: load to-binary decompress (card)
	append deck-cards dimg ;feel movestyle
	throw-away-label: label
	append deck-cards-num num
	append deck-cards-color color
	throw-away-pos: pos
]

random-card: does [pick deck-cards random length? deck-cards]
foreach c lc [set-face get c deck-cards]

view/new the-tableau

do-events

The plan was to read  card at random into a block called the-deck, 
then remove them one at a time, and add them to another block called 
the-tableau.

I've got important work to do right now, but if you can wait, I can 
give you a working solution later.

if you're on stack overflow, I'd even prefer you repost your question 
there, since Its going to be on the open web and I can post pictures.

And you will increase your rank for free Maxim ? ;-)

hahahhaa.

I still need to put the time to answer him  ;-)

srwill, Try to postpone the foreach statement in your code.

lay: layout the-tableau
foreach c lc [set-face get c deck-cards]
view lay

btw, using "the-tableau" , Are you from the French connection somehow 
?

No, tableau is a term I seem to recall from an old According to Hoyle 
card rules book, meaning the layout of the cards to be played.

Yeah but still, it's French.
It's like doing your coming out :-)

Rien ne va plus!

I had French in HS... couple semesters in college... Can't read that. 
 I do have great admiration for the French, though.

That's enough, you're officially adopted by the French community.

Tres bien!

Posted the question at Stackoverflow also: http://stackoverflow.com/questions/4073722/rebol-view-how-to-assign-images-to-layout-already-created

I'm working on it.

Note I added a bit of meat to the do-events topic raised by Graham, 
as an extra answer.

and yes... it would be swell if you rate the answer as the final 
one  (shameless I know, but worth the time and effort Me thinks  
;-)

Is there a way to make objects a and b such that operations like 
a + b make sense? Like a complex number object.

Geomol has done a complex number library.....Discussion is here:

   http://www.rebol.org/aga-display-posts.r?offset=0&post=r3wp381x1804

Thanks, Sunanda.

Geomol's complex number library represents a workable approach to 
implementing a large integer math library. But has anyone already 
implemented one? That is, bc's ability to do +, -, *, and / on very 
large numbers? I've been trying to call bc from REBOL using the CALL 
stmt, but success has so far eluded me.

I have an old string-math lib. I don't remember how complete it is, 
but the basic ops should work. May no be applicable to what you want 
to do.

There is this:
   http://www.rebol.org/view-script.r?script=bignumbers.r

But (from a quick squint) it handles numbers as strings. That may 
be less effective than the usual bignum approach [which, in REBOL 
terms, might be a block of 32-bit binaries]

Isn't there a libbc?

The block of binaries would give better performance, but the string 
approach might be fast enough. I'll take a look at it. Thx.

The application involves arithmetic associated with disk addresses 
which can be beyond 2 terrabytes.

Strings are probably fine for 12 or 13 digit numbers.

REBOL3 has 64-bit integers, so that is well within range of a native 
REBOL 3 INT.
Is R3 a possibility for your project?

Yes, it is. Native would be great. I just tried some simple stuff 
on R3 so I'll experiment further. Thanks a lot.

R3 is a little wierd in its handling of large hex numbers - it displays 
them in scientific notation with limited precision instead of as 
integers.

>> 0x3333333333333 
== 0x3.333333e12

That's not a hex number.
It's a REBOL pair.
For hex, try this:
  to-hex 333333333333

Which exposes a nice bug in A110. There is no longer an issue! type 
which can be used for arbitrary base literal numbers.

So to-hex is actually rather misleading.

(And should probably be removed.)

First of all, we never had a type that could be used for arbitrary 
base literal numbers, except the string types.

Next, TO-HEX should probably not be removed, but it should return 
a string! instead.

how would that differ from to-binary?

A binary is only formatted with hex characters (if the binary-base 
is 16). A string would actually containthe hex characters themselves.

So to-hex would be shortcut for enbase/base to-binary num 16. Rather 
useless.

But my, why not.

I expect that TO-HEX is a formatting function that is definitely 
not useless for web work, for example.

That usage would require that we keep the issue-generating feature 
though, even if we couldn't convert back easily.

Or you stop being lazy and add the # manually.

TO-HEX is a convenience function. Being lazy in a common situation 
is the whole point to convenience functions.

Being lazy means that there's no point to this discussion.

a nice bug in A110
 - And which bug is that, exactly? Has it been reported?

Nevermind.

Trying to find out the bug is why I spoke up in the first place. 
I am trying to get the bugs reported so they can be fixed, as appropriate. 
It's amazing how often bugs go unreported and thus unfixed.

No bug. TO-HEX works as designed. Nothing to see here, move on people.