World: r3wp
[View] discuss view related issues
older newer | first last |
Graham 20-Aug-2006 [5384] | Yes, that's where i saw it. |
Anton 20-Aug-2006 [5385x2] | I remember fiddling with it ages ago but I can't remember anything now.. :) |
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 | |
Volker 21-Aug-2006 [5387] | You could set system/view/caret to none in /redraw? |
Anton 21-Aug-2006 [5388x5] | 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] ] | |
Henrik 3-Sep-2006 [5393] | 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? |
Anton 4-Sep-2006 [5394] | How are you closing the informed windows ? Usually should be HIDE-POPUP (not UNVIEW). |
Gabriele 4-Sep-2006 [5395] | henrik, please let me know if you manage to reproduce that. |
Henrik 4-Sep-2006 [5396x2] | 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. | |
Volker 4-Sep-2006 [5398] | Also when you use "hide-popup"? Else maybe the auto-close has a bug, does a 'unview only? |
Henrik 4-Sep-2006 [5399x4] | 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? | |
Anton 4-Sep-2006 [5403] | Yes it does. |
Henrik 4-Sep-2006 [5404] | 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... |
Anton 4-Sep-2006 [5405] | 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. |
Henrik 4-Sep-2006 [5406x2] | that would just cause a crash to console, wouldn't it? |
e.g. couldn't find an object in parent-face | |
Anton 4-Sep-2006 [5408x3] | Yes - sorry, that problem is probably not exactly related to yours. |
What the wierest thing your toolbar does ? | |
wierdest | |
Henrik 4-Sep-2006 [5411] | trying to create a separate applicaton and torture toolbar that way. it happens if I update toolbar and recreate its contents exactly 19 times. |
Anton 4-Sep-2006 [5412x3] | weirdest |
Cool. Keep on it. | |
You released the toolbar somewhere... | |
Henrik 4-Sep-2006 [5415x4] | 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 | |
Anton 4-Sep-2006 [5419] | and is your code to show the bug shortish ? |
Henrik 4-Sep-2006 [5420] | 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 |
Anton 4-Sep-2006 [5421] | I would make a "debug" copy of the complex application, then cut out chunks until the bug no longer appears. |
Henrik 4-Sep-2006 [5422x3] | 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. | |
Anton 4-Sep-2006 [5425] | 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... |
Henrik 4-Sep-2006 [5426] | I could try disabling it... |
Anton 4-Sep-2006 [5427x2] | 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. | |
Henrik 4-Sep-2006 [5429] | true, but it will be very time consuming... |
Anton 4-Sep-2006 [5430] | 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. |
Henrik 4-Sep-2006 [5431] | well, DRAW isn't the culprit |
Anton 4-Sep-2006 [5432] | Ok, so my first guess has removed a small amount of code. (wouldn't it be better if it was 50% of the code ? :-) |
Henrik 4-Sep-2006 [5433] | http://hmkdesign.dk/rebol/toolbar/toolbar-demo.r<--- I don't know if the bug shows here |
older newer | first last |