World: r3wp

Ashely ... Windows tablet OS support in RebGUI ?  Feasible?

Input panel support works with View, native support requires MS compilers.

Can I use bold for selected rows of table widget?

there can be multiple selected rows actually?

hmm, that is something which is not planned for grid ....

in two weeks I will have something for you to test. Actually, we 
could release it sooner, but it is preliminary imo, as Cyphre is 
finishing hilighting, adding keyboard navigation, etc.

I observed it already - but what I want is to mark some rows with 
bold or other color or something similar.

but so far, I am very satisfied, the grid does tri-state columns 
sorting, functions for insert, remove, swap columns were added, you 
can have whatever element in cell, etc.

Janeks - usually, if I need something like that, I add column with 
checkboxes ....

How to... ?

well, not sure about tables, but new grid will allow that ...

even 0.3 version was imo better than what table offers .... I was 
quite surprised, how anyone can use that for real application?

I do. Table is good for text-only multiple column rows where you 
don't need cell-level addressing. Grid will satisfy those who need 
something more complex ... but don't confuse functionality/complexity 
with "better". Table meets *my* needs, Grid meets *yours*; and folks 
can choose to use the most appropriate one for the task at hand. 
Choice is good.

Most of the time I have no need for cell level addressing so the 
table works fine.  But I could use a grid someday ...

but a table that could colour rows would be very nice too

I do not need cell level adressing. It could be even enought with 
simple list. It seems that in begginging I will use them and for 
statuss changes use just some part of text or some symbols:
F.ex:
Msg#1 2006-Jun-01 Unread
Msg#2 2006-Jun-01 Read


But any way -  what could you recoment to use for scrollable list 
with either changeable colors, font styles or including some small 
icon?

For VID, use list-view

Thanks - looks nice - have to try!

I need horizontal scrolling, not cell level adressing so much .... 
table is simply not of much use for most database driven apps ... 
not sure how you design your apps, but I tend to have more than one, 
two, or three columns to display. There is no solution for rebgui 
currently. I do agree, that choice is always good. Btw - the bug 
with scrolling hilite under the horizon is still present with table 
:-)

Pekr: yesterday I fixed the 'scroling bug' in table. Will post it 
to SVN soon.

ah, thanks :-)

forgotten, how to display a particular tab programmatically?

(Just posted table and couple of fixes and enhancments to SVN.)

guys, those of you, working with databases - currently in new grid 
implementation, there are insert column, remove column, swap columns 
functions. Those do physically alter order in block of blocks (data) 
section. Apart from possible speed limitations, do you think it would 
be better to just virtually swap, insert (at the tail), remove (just 
make it invisible), or is it ok?

has it any impact of possible update call to the database? Just thinking 
lound ... hiding columns is ok, but if user changes their order, 
data changes too ....

Short note: Cyphre did, what I call, an input-grid. It's a static 
grid that you can specify which even generates names to access the 
cells. Might be useful in many cases as well.

Hi, I would like to get some feedback on some rebgui-grid decision. 
The thing is, I need to do it till tomorrow, to stabilise a bit and 
go for more final version ....

So - you can look at the latest screenshot here - http://www.xidys.com/rebgui-grid.jpg

The thing is - one one hand, I don't want grid to be as capable (and 
big) as Henrik's grid, otoh it would be good to offer some functionality 
commonly needed for DB apps ....

The issue I am trying to currently adress, is that of (non)modifying 
original data block, and here come some questions ....

currently functions like - swap-columns, insert-column, remove-column, 
work with real data block, whereas sorting column introduces virtual 
adressing. You can still access raw data by going to grid/content/2/2 
or so, but if you want to get sorting reflected, you need to use 
API ....

what I am thinking about is to virtualise even things like insert-columns, 
remove-column (then hide-column becomes redundant), swap-columns, 
so that original data block would not be changed, which can be usefull 
for easy updates to sql directly from data block .... what do you 
think?

I'm doing that in LIST-VIEW and it can easily be done fast enough, 
if you are worried about performance.

you are doing what - virtual access, or raw changes?

although, I can't produce virtual columns

virtual access of both rows and columns

sorry, rephrasing virtual columns: specifically new columns that 
contain new information derived from existing columns

ah .... ok ....

how do you solve possible change to amount of data? My friend working 
with SAP grid suggested to me simply keep index block, and assign 
each record a recno virtually, as with update, in multiuser system, 
there could come some new records, or some may disappear ....

if I have two real columns: height and width, I can't produce an 
area column with the product of the two first columns and show that 
next to the first two columns.

I am not sure I understand :-(

yes, I calculate an index block every time the list is updated with 
new information. I use that index block to display the raw data in 
the sequence I want.

no matter, it's not so important. :-)

in my experience, data manipulation is never a performance issue. 
what is a performance issue, is related to VID and SHOW

that's why I built in options to turn off updating when doing multiple 
operations. by doing that, operations can speed up tremendously.

At what "size" of array do you notice slow downs?  We are about to 
add a simple spreadsheet to Qtask.  We will be facing the same issues. 
 In our case we will be using Javascript on the front end, but the 
issues are similar, we have to decide which parts work on the client 
(virtual as you would say), or when we do a complete refresh.

I think it's depending on view size rather than the number of cells. 
A list with 10x10 entries in a 300x300 configuration can be faster 
to scroll than a 5x5 in an 600x600 configuration. LIST-VIEW uses 
iterated faces to generate the entries, so whenever the list view 
needs to be updated in just one cell, the entire list face is rerendered 
automatically.

also I don't really notice slow downs on very large arrays, because 
I always work from a sorting index, a plain 'pick of the row need 
from the data array. this is pretty fast.

Yeah, that was my expectation.

if SHOW was much faster, LIST-VIEW could be insanely fast. you could 
probably easily scroll a 50x50 array in fullscreen 1024x768 at 25-40 
fps. I've noticed that when doing manipulations when not updating, 
such as sorting and moving entries in one go, these things are close 
to instant. The MOVE-ROW-UP/DOWN operations work like that.