World: r3wp

anyway - please RAMBO it.

is this just a recursive crash ?

gabriele, in my program it was triggered by closing an inform window, 
but after stripping away all the code to the above, it didn't have 
anything to do with it. It merely triggered the bug accidentally.

anton, in the "insert tail pane: []" part, it will still crash, when 
using copy on that array

Yes, it looks like maybe the View system can't handle too much recursion 
while processing events. It's still fairly serious as it shuts down 
rebol.

anton, interestingly also, speed has nothing to do with it. you can 
do the same thing at keyboard typing speed.

(that is, run each iteration at keyboard typing speed, not full rebol 
light speed :-))

must go - more investigation later... :)

graham, some kind of buffer overflow I think. The more code that 
is used in the toolbar, the fewer iterations it requires to crash 
REBOL. In my program it takes 10-20 iterations to crash it.

if this can't be cooked any further down, I'll RAMBO it.

done

does anyone have a fix for SCROLLER, so that scroller buttons don't 
move the scroller only one pixel at a time when the scrollbar is 
only slightly smaller than max size?

The STEP facet controls how much the scroll buttons change the data 
value.

view layout [scroller with [ratio: 0.9 step: 1 / 10]]

Here I set RATIO to 0.9 which represents 90% of the total data.

The calculation is     step = 1 / (total rows - visible rows)

In my scroll-table style, what I do when resizing is this:

 vscroll/ratio: rows / (1 + length? list-data) ; visible rows over 
 total
	vscroll/resize vscroll/size: (calculate new size here)
	; step = 1 / (total rows - visible rows)
	use [y][
		y: max 0 ((length? list-data) - rows)

  vscroll/step: either 0 = y [1][1 / y] ; prevent division by zero
	]

Don't be worried that the unit of my data is rows of text and not 
pixels, it should be the same calculation.
Just change: 
	total rows  (length? list-data)  -->  total height in pixels 
	visible rows  (rows)  --> visible height in pixels

I've studied the problem now, and it's the same algorithm as I use 
in LIST-VIEW, but it's defective and causes the scroller only to 
move 1-2 pixels at a time, when the list is only slightly larger 
than the visible area. I found a different solution which was not 
to trust the step at all and use LIST-VIEW's own function to move 
the list and scroller separately, i.e. the list position is not derived 
from the scroller anymore.

I think the solution currently used in SCROLLER only works when you 
want smooth scrolling.

I think doing it that way can also avoid floating point rounding 
errors, which would sometimes cause two rows to be stepped instead 
of one (or the opposite, zero rows were stepped).

I found an interesting scenario, that I'd like to know if it will 
be possible to fix. Maybe it's the wrong approach, but here goes:


I've wrapped an entire app in a TRY. Theoretically, then if the app 
crashes to console, it will be handled and the error disarmed. The 
error object is then sent to an INFORM window which displays a nice 
crash requester which offers you to send an error log and a description 
of what you were doing at the time of the crash to me via the internet.


This works fine for the most cases, but I noticed an error that was 
caused during a mouse drag operation. When dragging, the requester 
will pop up, but events are still flowing in the window that caused 
the error. When I release the mouse button, it then crashes one more 
time and this time brings up the console, ruining the purpose of 
my nice crash requester.


What should have happened was that the INFORM window should have 
blocked all events from other windows, so the application would stop 
to a controlled state. Is there a way to block events like this or 
is there another way around this?

Maybe clear the event port as soon as you get the first error.

.. by doing
	pick system/view/event-port 1
until it returns NONE

(Just like system/view/wake-event does)

is there a guarantee that it will eventually return none?

Um... if you remove event-port from the wait-list.

remove find system/ports/wait-list system/view/event-port

You can put it back when you want to process events again.

insert system/ports/wait-list system/view/event-port

So:

      remove find system/ports/wait-list system/view/event-port
      until [none? pick system/view/event-port 1]
      insert system/ports/wait-list system/view/event-port
      inform my-crash-requester

That looks right.

I will test it soon...

Let us know.

no go... maybe it's how the error is handled.

well.... by using a VIEW instead of INFORM, the window which catches 
the events is closed thereby not bringing up the console. it looks 
rather abrupt, but better than nothing.

i would try an event-func. You know how to catch a close-event for 
a specific window, drop events for that window the same way.

in the detective, i had the same problem (but with network events 
coming). i just clear the wait list and show the inform. maybe you 
could also add a custom event func that filters events except for 
those regarding the popup.

Henrik, maybe it's better to patch wake-event, then, which gets the 
events before they are sent to the window.
	probe get in system/view 'wake-event
Trap errors during DO EVENT like this:

	if error? set/any 'err try [
		do event
	][
		; stop more events and handle the error
	]

Henrik, maybe you can post us a cut-down example which shows the 
double-error bug, and we can try to handle it the best way. Sounds 
like it would be a useful technique in general.

if error? program-error: try [
  view layout [
    h3 "Avoid the console from popping up"

    box 500x100 "Hold down left mouse button and drag to create errors" 
    feel [
      engage: func [face act evt] [
        if find [over away] probe act [
          2 / 0 ; error!
        ]
      ]
    ]
  ] do-events
] [
  ; what to do here to block the events from the view window?
  error-obj: disarm program-error
  inform layout [
    h3 "Program Error!"
    area 300x200 mold error-obj
    button "Close"
  ]
]

that 'do-events should probably not be there... sorry

This is a working test-programm?

yes

the view layout block is supposed to represent the application

My first suggestion (just PICKing all events) doesn't work. I don't 
see another way to clear the event port, so I'm going to try patching 
wake-event, which is where you can prevent DO EVENT from sending 
the event to engage.

Hmm, seems it bypasses event-funcs. should that happen?

rebol [title: "scratch"] 
if error? program-error: try [
    view lay: layout [
        h3 "Avoid the console from popping up" 

        box 500x100 {Hold down left mouse button and drag to create errors} 
        feel [
            engage: func [face act evt] [
                print ["engage" face/text]
                if find [over away] probe act [
                    2 / 0
                ]
            ]
        ]
    ]
] [
    print "error" 
    insert-event-func func [face event] [
        print ["event-func" event/face/text event/type] 
        either same? lay event/face [
            prin "mjam" 
            none
        ] [
            event
        ]
    ] 
    error-obj: disarm program-error 
    inform layout [
        h3 "Program Error!" 
        area 300x200 mold error-obj 
        button "Close"
    ] 
    print "inform done"
]

Aha, what you have to do is catch errors around both instances of 
DO EVENT in wake-event.

error-window: layout [
	h3 "Program Error!"
	area 300x200
	button "Close" [hide-popup]
]

inform-on-error: func [code [block!]][
	if error? set/any 'error try code [
    	error-obj: disarm error
    	?? error-obj
		error-window/pane/2/text: rejoin [
			mold disarm error 
			now/time/precise
		]
    	either viewed? error-window [
    		; subsequent errors
    		show error-window
		][
			; first error
			
			print "INFORM"		
			;inform error-window
			; Emulate INFORM but without WAIT
			error-window/text: "Dialog"
			error-window/feel: make system/view/window-feel []
			show-popup center-face error-window
		]
	]
]

system/view/wake-event: func [
	port 
	/local event no-btn error ; <-- added 'error
] bind [
    event: pick port 1
    if none? event [

        if debug [print "Event port awoke, but no event was present."]
        return false
    ]
    either pop-face [

        if in pop-face/feel 'pop-detect [event: pop-face/feel/pop-detect 
        pop-face event]
        inform-on-error [do event]
        found? all [
            pop-face <> pick pop-list length? pop-list
            (pop-face: pick pop-list length? pop-list true)
        ]
    ] [
    	inform-on-error [do event]
        empty? screen-face/pane
    ]
] system/view

view/title layout [
	h3 "Avoid the console from popping up"

 box 500x100 "Hold down left mouse button and drag to create errors" 
 feel [
		engage: func [face action event] [
			print ["ENGAGE:" event/time event/type mold event/face/text]
			if find [over away] action [
				2 / 0 ; error!
			]
		]
	]
] "Main Window"