World: r3wp

options [info] was replaced with set-disable and set-enable .. and 
you can specify disable like this as well:

display "Test" [
	field
	f: field disable
	field
	button "Off" [set-enable f]
	button "On" [set-disable f]
]

I've been looking at the jqGrid ... http://www.trirand.com/jqgrid/jqgrid.html
and many of these grids use a data source instead of a static block 
of data.

(see why I'm keen to redo the docs :) )

why not just ... set-enable f true/false

with a data source you can let the pagination occur within the widget

And let the widget handle the "loading ..." indicators

What I do at present is use a tab-panel and have the loading gif 
in one, and then replace that panel with the table once the data 
arrives

Having pagination would really help a lot ... sometimes i have tables 
full of hundreds of items.

why not just ... set-enable f true/false
 ... makes sense, I'll think on that one
use a data source instead of a static block of data
 ... live data?

sql query

What do you mean by pagination in the context of a table?

say you have 1000 rows... but you only want to display 20 at a time

having all the data inside the table at once means big slow down 
time

better to feed the table from a sql query, or another function that 
holds all the data

so you can use the scroller to move within the 20 items .. but not 
to scroll past them.  You have to paginate to the next 20.

The slow-down is from the query side not the RebGUI/table side. Table 
uses an iterator function so whether the table has 10 rows or 1,000,000 
it should be the same speed ... fetching 10 rows or 1,000,000 across 
a network is another story.

That's not my observation.

Anyway, 20 rows will be faster than 40 right?

Anyway, scrolling thru 1M rows is impractical.

I presume altme uses an iterator function as well... I just switched 
from 1000 to 4000 in preferences and now scrolling is a dog.

Try this on 10, 100 and 1,000 rows:

d: copy []
loop 20 [insert tail d reduce [random 10 random 10]]
s: now/time/precise
display "A" [
	table 20x100 options ["A" left .5 "B" left .5] data d
]
print now/time/precise - s

seems to scale pretty well here (on a Mac).

(replace loop 20 with loop n)

Back to your request-value question, does the prompt for:


 request-value "Enter the url for your website here. It looks h t 
 t p ://www.site.com"


appear on 3 lines? If so, what would you enhancement request (vertical 
layout option) do? (not wrap the prompt and extend the field width 
to match prompt text width?)

the prompt doesn't wrap currently ...

I'd just want an after 1 layout I think

What build# are you running?

I tried your latest

as for the table scrolling ... yes, it is fast.

Did you change the table routines recently?

In my app, I have 24 rows, and there is a definite lag belween the 
scroller and what I see on screen.

ie. the scroller lags behind the mouse as it drags it up and down.

The underlying face-iterator hasn't changed much, but the slider 
code was totally rewritten ... so it *might* have been the slider 
widget?

I'm using the table from prior to the big color changes

Going to try the older rebgui....

Wow .. huge differences

Even with only 50 items there is a noticeable lag with the older 
table.

The rewrite was worth it then ;)

Yes .. definitely .. although I can't use it without breaking my 
application

Did you always use iterated faces for the table?

Could it just be the scroller?

Yes and yes.

Ok.

And before you ask, back-porting just the scroller is not viable.

I erased that response I was about to make!

Back to your request-value prompt wrap issue ... I just tried it 
under WinXP with build#212 and I get 3 wrapped lines of text. Does 
your requestor have a big blue question mark icon in the top-left 
corner?

Yes

Are you on WinXP, Vista or Win7?

Looks like the scroller issue goes back a while .. I tested the version 
where you had the color changes and that is also fast.

Windows 7 RC1

let me check the source ..