World: r3wp

Is copybtn a hidden button that your action tries to make visible?

the button's visibility depends on which tab is showing.

Let me check to see what the initial state is ...

No, initial state is visible.

I presume the problem is with 'layout

some change in the latest build

the button is defined after the action, so 'display can't find it...

Can you reduce the problem to a small sample and post here? Layout 
hasn't been changed but the way in which tab-panel initializes has.

I'll try ..

been trying all morning !

what to do about the tabbing?

I'm going crazy .. what's wrong with this ?


display "" [ button "new window" 40 [ display "" [ text "helllo"]]] 
do-events

the button doesn't do anything

On another topic, I often find I need symbols such as those in a 
music player (stop, forward, fast-forward, etc) and in lieu of a 
cross platform "symbol" font I'm thinking that a symbol widget using 
AGG might be the go. Would work something like:

	display "test" [
		symbol data 'square
		symbol data 'arrow-right
		symbol data 'double-arrow-right
		symbol data 'circle
		symbol data 'circle options [no-fill]
	]


so the two questions are; would this be useful, and if so what would 
constitute a good set of symbols and names?

what's wrong with this?
 display expects a unique title string. ;)

aww.. crap

Try this one ...

rebol []

do %rebgui.r

show-bug: does [
	display "test window" compose/deep [
	tab-panel 80x20 data [
		action [ hide e ]
		"1" [
		]
		action [ show e ]
		"2" [
		]
	]
	return
	e: button "Invisible"
	]
]


display "Test"  [

 label "field has a focus action" a: field [ print face/text ] return
	label "also has action" b: field [ print face/text ] return
	label "no action" c: field return
	spinner options [ 9:00 24:00 0:30] [ print face/text ] return
	button "Display tab-panel" 40 [ show-bug ]
	return
	
	button "Quit" [ unview/all halt ]
		
]

do-events

>> do %debug-rg.r
Script: "Untitled" (none)
Script: "Untitled" (none)
** Script Error: e has no value
** Where: action
** Near: hide e

Ah, the "problem" here is that the action associated with tab 1 is 
now firing when tab-panel is initialized, which occurs prior to e: 
button being created. I can add an option to tab-panel to prevent 
it from firing the tab 1 action (i.e. revert it's behaviour to previous). 
Or should the default behaviour be what it originally was with an 
option of firing the first action?

latter I think.

keep it safe.

are you symbols clickable?

are your ..

I mean, they are custom buttons are they not ?

Yes. Wait a moment and I'll get another build with the tab-panel 
and spinner fixes up ...

build#56 committed to SVN.


 tab-panel now only fires action on initialization if options [action] 
 specified
	spinner now fires action after arrow click

 arrow has default size of 5x-1 (meaning you can now create non-square 
 arrows ... needed by spinner above)

going to check it out now :)

I've just noticed something odd with tabbing inside a tab-panel. 
It tabs through all widgets on every pane!? I need to look at Cyphre's 
edit (cyclic?) changes I think.

tabbing is very suspect

I think I've mentioned it before :(

spinner arrows too large .. can only see the top one.

I only updated spinner and tab-panel though ..

ahh.. rebgui-ctx also has changed

Need arrow as well.

rebgui-ctx has to be updated each build as that is where the build 
number is set (displayed in %tour.r).

Ok, got it.

tabbing is very suspect

 Agree, it used to be simple and work well ... then folks started 
 wanting stuff like full keyboard navigation. ;)

keyboard navigation is however the only way to drive a gui at full 
speed .. by ignoring the gui!

Use REBOL/Core and an ASCII interface then! ;)

can the increment value in a spinner widget be changed dynamically?

I was watching the girls at the office drive an EMR ... all done 
by keyboard navigation.

very quick.

but of course there is a lot of training required to learn all the 
keys ( shift, control, alt on every key )

Yep, as can min and max (e.g. s/options/3: val).

ok

all done by keyboard navigation.

 as long as the widgets don't require much internal navigation. There's 
 a world of difference between a screen with 12 fields and one with 
 drop-downs, tables, scrollable areas, check boxes and radio buttons 
 (to name a few).

I suggest that for spinners, allow users to start with a blank spinner 
so that they can type in their own initial values.

the value can then be co-erced to the same type as the max/min

when I tried this using an empty string as the initial value in the 
example above, I got this

** Script Error: Expected one of: string! - not: time!
** Where: unfocus-action
** Near: face/text: form face/data: min max

since the spinner is editable by the user, any values not entered 
of the correct type will presumably crash the app.