World: r3wp

I've figured out a way to avoid showing the caret for you custom 
styles. It requires patching FOCUS and using insert-event-func to 
install a handler that sends key events to the focal-face when there 
is no caret.  (DO EVENT won't do that, so we have to.)
See http://anton.wildit.net.au/rebol/patch/focus-system-patch.r

You could set system/view/caret to none in /redraw?

Hmm.. temporarily setting caret to none - let me try that.

First test - does not appear to work...

I think the caret is rendered after the redraw finishes, so fiddling 
with caret between SHOW and DRAW actions of redraw won't make any 
difference.

Here is what I tried:

; Redraw action SHOW occurs first, then DRAW.

view center-face layout [
	f: field feel [
		crt: none 
		append body: second :redraw bind [

   either act = 'show [crt: system/view/caret system/view/caret: none][system/view/caret: 
   crt]
		] body/3/2
	]
	field 
	do [focus f]
]

I'm getting hard crashes when closing an 'inform window sometimes. 
If I change the windows to view/new they no longer happen, but I 
lose the always-on-top functionality.


I was wondering if anyone has experienced similar crashes and know 
a precise cause? Perhaps some events are blocked?

How are you closing the informed windows ? Usually should be HIDE-POPUP 
(not UNVIEW).

henrik, please let me know if you manage to reproduce that.

It's a little difficult, because it's a rather big VID application, 
but it happens very often and always when the window is closed. Unfortunately 
I can't spread this app. I can't reproduce it accurately every time, 
but it seems that a certain amount of keyboard input in that window 
must be involved before it happens.

Anton, I simply click the close button [X] on the window.

I have 3 different inform windows and it definitely happens in 2 
of them, always when clicking the close button.

Also when you use "hide-popup"? Else maybe the auto-close has a bug, 
does a 'unview only?

haven't tested with that yet. I have a custom event function for 
closing the main window:

insert-event-func func [face event] [
  if event/type = 'resize [
    help-window-resize
    main-resize
  ]
  either event/type = 'close [
    either event/face/text = main-window-title [
      if request/confirm "Afslut programmet?" [quit event]
    ][
      event
    ]
  ][
    event
  ]
]

It happens also when using HIDE-POPUP

hmm... this is something that goes on in my toolbar code, so it should 
not happen with VID in general. it's still a strange error however. 
a face simply disappears from a PANE block :-)

does SHOW set the parent-face automatically in subfaces of a pane?

Yes it does.

it's when I do a SHOW on the toolbar that it crashes, but I'm still 
miles away from what exactly is going on...

Actually, the opposite can be a problem - expecting parent-face to 
be set before the face has been SHOWed. eg. you have LAYOUT a window, 
but not VIEWed it yet.

that would just cause a crash to console, wouldn't it?

e.g. couldn't find an object in parent-face

Yes - sorry, that problem is probably not exactly related to yours.

What the wierest thing your toolbar does ?

wierdest

trying to create a separate applicaton and torture toolbar that way. 
it happens if I update toolbar and recreate its contents exactly 
19 times.

weirdest

Cool. Keep on it.

You released the toolbar somewhere...

uhmm... not sure about weirdest :-) but I build the toolbar layout 
from a block that is parsed, appending faces and their attributes 
as it gets parsed. when that's done, I show it..

can't remember if it's the latest version... it has a few extras

http://hmkdesign.dk/rebol/toolbar/toolbar.r

it's pretty new

and is your code to show the bug shortish ?

I'm not done with it yet. I still only have seen the problem in the 
complex application, but the test code is so far about 15 lines

I would make a "debug" copy of the complex application, then cut 
out chunks until the bug no longer appears.

the thing is that it happens when I close an INFORM too

but I'm not sure about the relation between that inform and a toolbar 
update.

:-( ran 2000 updates on the test version without problems.

Just looking at the toolbar code, I suspect the DRAW dialect, perhaps 
it is the use of FILL-PEN LINEAR ? I seem to remember a bug there...

I could try disabling it...

Well, the best idea is to start with a copy of the full app, as I 
suggested above. I've done the same thing as you, trying to track 
down bugs, trying to guess what it is.

Guessing is cool but it's not as sure as subdivision.

true, but it will be very time consuming...

Can be hard sometimes to remove certain chunks, but usually you can 
disable large chunks of code using comments, verify that the bug 
is still there, then remove the code - and repeat until there's not 
much left and the bug is obvious.

well, DRAW isn't the culprit

Ok, so my first guess has removed a small amount of code. (wouldn't 
it be better if it was 50% of the code ? :-)

http://hmkdesign.dk/rebol/toolbar/toolbar-demo.r<--- I don't know 
if the bug shows here

the thing is, what if it's a buffer overflow? that will be really 
hard to fix, because you might run into the bug randomly.

It could be. But never miss a chance to find a deterministic View 
bug. :)