World: r3wp

Before adding new function to the list widget I'm actually tryaing 
to improve de yet existing things in order to not have to work on 
it any more later. So I work on order symbolisation (thank you ashley 
for the inspiration) and on column resizing algorithm and visuability 
:)

http;//shafwolf.free.fr/rebgui-list47.r

http://shafwolf.free.fr/rebgui-list47.r

for new demo version :)

dab adress sorry http://shadwolf.free.fr/rebgui-list47.r

>> ** Script Error: Cannot use add on none! value
** Where: do-body
** Near: ar-wid/header-ind + 1

but the gadget is still working

yes sorry same link for corrected version

I fixe it some minutes ago but I don't mention it here ...

Ichnaged the over function content for header buttons too ... now 
it shows/hide the sorting indicator

I see now you can not collapse a column to zero width as before

yes I find this better this is driven by the need to display the 
order symbol if the column will make to 0 size the symbol will not 
be related to the adecate column

showing a order symbol for the non adecate column is not a good thing 
...

ordering = sorting order = sort sorry false friend with french work 
ordre ;)

not work but word ;)

This widget is becoming very cute :-) Good work.

So how to best handle data now? For example I want to handle a todo 
list, where I need to change position of the todos in the list. Does 
the widget works with copy of the data best, or can I link it directly 
with the data block that the other functions work with too?

widget are not yet linked with the data content modification for 
example check box doesn't modify it's related datas into the  listview/data 
field

I need to work the modification code

there is  2 kinds of modification 1) internal made by action capable 
widget 2) allowing external insert of new lines of data then build 
the table

Latest build available at: http://www.dobeash.com/files/RebGUI-022.zip

Highlights include:

	- Added drop-list, edit-list and auto-fill widgets
	- New splash function added (run %tour.r to see it in action)

 - Window management logic improved (disallows duplicate windows and 
 "sticks" child windows to first)
	- Couple of minor fixes and cosmetic improvements
	- %tour.r has an additional "List" tab

 - Prototype table widget added (run %table-002.r to see it in action)

Known issues

	- spinner and auto-fill widgets need more work
	- edit-feel needs to handle highlight, cut & paste
	- scroller needs more work (resizeable dragger)
	- table needs row selection logic added
	- edit-list needs auto-fill logic added

In progress

	- Improved tab-panel
	- Menu
	- tabbing
	- field input validation (field input masks, etc)
	- list-view (shadwolf)


With regards to "lists", I envision 5 types we need. They are (in 
ascending order of complexity):


 drop-list	- non-editable, single sorted column with single value 
 selection [optimized for < 100 values]

 edit-list	- derived from drop-list but editable with an auto-fill 
 field

 table		- multi-column representation of a DB table; used to create 
 something like a GUI SQL client with single-row selection [< 100,000 
 rows]

 list-view	- multi-column multi-media content (supports images, URL's, 
 etc); used to create something like a file explorer with single perhaps 
 multi-row selection [<10,000 rows]

 grid		- cell-level addressing and editing supporting simple spreadsheet 
 formulas and formatting [< 1,000 rows]

Every time the quality of RebGUI increase. Every new version is a 
must one.  Good job every one ;)

What about a single column text-list? IMO this one is needed too.

could be usefull to make only single column lists, but make them 
share the same scroll

Yes, this would allow to build simple tables that move in sync.

another trick is to focus on the headers, and let the list-part be 
build by the user. where the header keeps some info for the list, 
like the column-width/resizing.

third, keep a user-reference in the row, where user can refer back 
to the real data.

RebGUI is looking nicer with every build.

Could you make the drop-list - with the auto-fill too? even if it's 
not editable.  Would make easier to find a value.

if it's not editable how dare you want to input text ?

Luisc: It's on the ToDo list. From the release notes above:

	Known issues
		...
		- edit-list needs auto-fill logic added

Could you make the drop-list - with the auto-fill too? even if it's 
not editable.  Would make easier to find a value.
 I think he is really talking about drop-list not edit-list ...

Hi. Back after one week spent in Buddhistic ashram :-)

I just tried RebGui 022 and would like to report something: Lists 
- once you open selection menu, you can't close it by clicking outside 
of it. ESC works, which is good, but clicking outside the menu should 
close it imo ...

requestors are nice!

What hits my eye a bit though is LED design - too boxy/narrow in 
comparison to check-boxes, radio-buttons etc. The color is a bit 
obtrusive and maybe not all their area needs to be filled with particular 
color? But that is just very cosmetic detail ...

What bothers me more (although with older View 1.2.46 - the memory 
consumption starts growing, even if I do nothing. Anyone noticed 
anything like that?

the event system does that - after a while, some megs, it should 
be garbage collected

A 'recycle was done by RebGUI in earlier versions (patched 'show 
function)

thanks ...

the problem of a recycle into show is tha it's performance consumer 
...

maybe we need to talk to carl about this point in order for him to 
make a more efficient way to garbage collect ...

and ofcourse conserving a good process speed :)

maybe it could be preferable to desalocate a content automatically 
when the content change ....

but this is an improvement internal to Core functionnalities ;)

when you do a: 123 then a: "fdsbfsdjbh" it would be interresting 
to detect if the a word yet exist and then trash the interger (123) 
content of this word and then allocate to the word a the string! 
new content.. this will be an internal  totally transparent way to 
handle memory allocation /deallocation

and this will influence every var content (I think that's better 
than having memory leak when event are used ....

new GC is inserted into 102 version but I francly don't see any différence 
in tour.r with RebGUI 0.22  we start a 6800 Ko and the memory is 
cleaned when 8500 Ko is reached and cleaned  to 7400 Ko ...

(regarding de/allocation) I don't know if it would change something 
in our case: in /View, event objects are generated by user/system. 
The event object carrying mouse 'move information may not be used, 
but one can only know and discard it at the end of the event processing 
chain (a global event-func or a face feel) - could be tricky to do

new GC: it must be various corrections to crashes and speedups. I 
don't know if anything has changed on conditions for garbage collection 
triggering.