World: r3wp

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"

Just got to figure out how best to continue waiting for events when 
the popup is closed...

Too sleepy now...

Actually, I don't see the benefit in making the error window a modal 
popup. What would be cool would be to have a gadget to show multiple 
error messages stacked on top of each other, with a couple of arrow 
buttons to cycle through them and a button to discard the currently 
viewed one.

The goal of the error capture is to provide end users a means of 
reporting bugs to me over the internet in a uniform manner. Having 
them read me console output over the phone just doesn't work.

To reach that goal I defined some rules:


1. The user must know what is going on when that window is popping 
up. Therefore it has to be very simple and clear that the program 
they were working in, has failed.

2. When I use the program, the error window must be useful to me 
as well, so I output the error object in that window.

3. The error window must pop up in front of the other windows and 
be modal. I've had way too many user cases with hidden new windows 
to great confusion of users. That's why I use an INFORM.

4. The program must stop dead in its tracks, because of two things:

4.1. The program saves to disk very often. If the program continues 
operating despite this error, there could be a risk of data corruption, 
which could be saved to disk, overwriting good data.

4.2. If the program crashes during receiving events from a moving 
mouse, the error log would become very big in no time, if the logging 
functions are triggered because of this mouse movement. It's important 
to see the first point where it breaks.

I've got all bits working except the event blocking part.

That's a pretty good logic.

New windows can be brought to front (or if they are minimized, flashed 
in task bar) with:
	window/changes: [activate] show window
which you could do insistently on new errors.

But ok, you want to stop on the first error. Ok, so you're using 
a modal window.
In that case, I would change
	inform-on-error [do event]
to:
	filter-do event


where the FILTER-DO function is the same as INFORM-ON-ERROR except 
it examines the event first.

When event/face = error-window, then DO EVENT, else discard the event.

why do you think the lines do not "meet" at "the corner"?


view layout [box 600x600 effect [draw [line 490x473 490x8 line 45x8 
490x8 polygon 45x473 156x357 490x8]]]

Good question. I think it may be a deliberate offset added to the 
some edges of polygons, so polygons with common edges can be drawn 
in any order without any overlap. This is used in 3D modeling, where 
lots of triangles with common edges are drawn.

I would check the AGG documentation to confirm that though.

Thi si because the defual mode for LINE-JOIN is MITER. It is enough 
for your case to change it to BEVEL,ROUND or MITER-BEVEL mode. For 
example:


view layout [box black 600x600 effect [draw [line-join bevel line 
490x473 490x8 line 45x8 490x8 polygon 45x473 156x357 490x8]]]

You can see the effect of different LINE-CAP/JOIN modes in Rebol 
Desktop: REBOL/View Tests/Line Cap Join


(or directly from console: do http://www.rebol.net/tests/line-cap-join.r)

Thi si because the defual mode...=This is because default mode...

are there tutorials anywhere on writing your own style with stylize/master?

I haven't seen it, but apparently Cyphre did one in at the last devcon 
.. so have a look at his presentation?

I know that one but was looking for one that would explain the different 
parts better.

Ask all your questions here about any facets, then we can collect 
the answers into a document.

Someone made a very nice colour-wheel requester (at least I think 
it was a requester) at one time. I've found Oldes' color-lab.r which 
is just awesome, but I'd like to also find any others.

This would be really a needed doc. I haven't done it myself yet, 
because the startup time to collect all information snippets is to 
high.

It's a pretty huge task.

There isnt much different to plain faces. There is a block /init 
which is called after all arguments are loaded by 'layout. Arguments 
are put in the appropriate facets, if there are some of the same 
type, they are put in a block instead. so two colors go into /colors. 
There is some magic with keywords, which needs more space to explain. 
but for quick things you can pass args in 'with. Styles have their 
own source in /facets, so you can look there. Best with deskop/tools/vid-style-tree. 
Start fresh things with 'image or 'box,  examine things by with[probe 
self]. The rest is the same as plain faces, and there are some docs 
now.

/init is a block so its extensible by appending own stuff to it, 
so 
text  with[append init[ print "all args here" ]]

Henrik, are you wondering what stylize/master does or how to use 
it ? Or are you looking more for a style-creation guide ?


Usage of stylize/master itself is pretty simple, it takes a style 
spec and adds the new styles in it to system/view/vid/vid-styles, 
where all the default styles are kept, eg:
	stylize/master [my-box: box blue "hello"]
	view layout [my-box]


I often felt the need for an official document explaining all the 
things a style should satisfy to be "VID-compliant" and explaining 
each facet in detail, where and how facets are used by existing styles. 
But no such doc exists. I've been growing a pile of demos and text 
documents as I discover things.