Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

specifiv position in area

 [1/11] from: moeller_thorsten:gmx at: 22-Feb-2002 10:03


Hi Brett, i tried out the code from your latest post and received som strange results. if i don't modify the text associated to the area and put the cursor somewhere in the text, the insertion works pretty well. if i add some lines and the try the insert, the window dissappeares ( some sort of crash ). Any ideas for this behaviour? Thorsten

 [2/11] from: brett:codeconscious at: 23-Feb-2002 1:39


Hi Thorsten, I did reproduce the problem once but failed many other times to reproduce it. So I cannot say for sure what the problem is. If you have worked out how to produce the problem consistently then could you try to see if this code has the same problem please? view layout [ a: area "place your cursor then click button" button "insert" [ if all [ system/view/caret ] [ a/line-list: none ; *Forces recalculation of line offsets. system/view/caret: insert system/view/caret "<inserted>" show a ] ] ] Regards, Brett.

 [3/11] from: moeller_thorsten:gmx at: 25-Feb-2002 9:45


Hi Brett, your new sample avoids the crash of the window. During the weekend i found some time to work on the code and found out what "system/view/caret" is for (previously i didn't know that). So, the problem was that when i type some extra lines and then want to insert some text in or behind the new lines, a debug printout for "system/view/caret" returns none and gives an error for the insert function. Your new code avoids this crash problem, but still lacks the functionality of inserting text right after the new textlines. I found out that just refocussing the area solves the problem like: view layout [ a: area "place your cursor then click button" button "insert" [ focus a ;--a/line-list: none ; *Forces recalculation of line offsets. system/view/caret: insert system/view/caret "<inserted>" show a ] ] This solves the problem, but is not very nicefor a user, cause the window is blinking due to setting the focus. Is there a way that when the area is active it has the same color as being not active? Perhaps you, as a more advanced Rebol-Programmer, have a more elegant way to solve this. Thorsten

 [4/11] from: philb:upnaway at: 25-Feb-2002 18:03


Hi Thorsten, try view layout [ field silver silver area silver silver ] This should give you the save color in fields & areas when in focus as when out of focus. Of course you can use any color in place of silver. Cheers Phil === Original Message === Hi Brett, your new sample avoids the crash of the window. During the weekend i found some time to work on the code and found out what "system/view/caret" is for (previously i didn't know that). So, the problem was that when i type some extra lines and then want to insert some text in or behind the new lines, a debug printout for "system/view/caret" returns none and gives an error for the insert function. Your new code avoids this crash problem, but still lacks the functionality of inserting text right after the new textlines. I found out that just refocussing the area solves the problem like: view layout [ a: area "place your cursor then click button" button "insert" [ focus a ;--a/line-list: none ; *Forces recalculation of line offsets. system/view/caret: insert system/view/caret "<inserted>" show a ] ] This solves the problem, but is not very nicefor a user, cause the window is blinking due to setting the focus. Is there a way that when the area is active it has the same color as being not active? Perhaps you, as a more advanced Rebol-Programmer, have a more elegant way to solve this. Thorsten

 [5/11] from: brett:codeconscious at: 25-Feb-2002 22:16


Hi Thorsten, Well I've stuffed around for a long time and now throw up my hands. You are right, you solution does solve the problem. Phil has got a message about the colouring. Which would solve the blinking, but I would like to keep the colouring functionality. I have found that entering text and pressing the button is fine because the area does not lose focus. When you use the enter key, optionally typing some text after it, and then click the button - the area loses focus. I would like to know why this is. It is certainly important if you want to code up a "paste from clipboard" toolbar button. Anybody else got some clues? Brett.

 [6/11] from: rotenca:telvia:it at: 25-Feb-2002 16:04


Hi Brett,
> Anybody else got some clues?
All the problem arises from this func: system/view/screen-face/feel/event-funcs/1 (1 before any insert-event-func) which is the default func for handling events: func [face event /local fac][ if all [ system/view/focal-face event/type = 'down not within? event/offset win-offset? system/view/focal-face system/view/focal-face/size system/view/focal-face/dirty? ] [ fac: system/view/focal-face unfocus do-face fac none fac/dirty?: none ] event ] As you can see, a mouse 'down event unfocus the actual focal-face (and caret) and do-es its action, but only if the dirty? flag is true. This flag is high when the user changes some text in an area/field face. So when you type something, the dirty? flag is high and at the next 'down event (on a button, for example) the face will be unfocus-ed before your button action routine can take the control. --- Ciao Romano

 [7/11] from: moeller_thorsten:gmx at: 25-Feb-2002 18:07


Hi Brett, this is exactly what i am behind, to have a working "area" and to be able to make a selection in an other window where the selection should be inserted at the last cursor position in the area. There seem to be a problem of system/view/caret or the area itself to keep track of datainput. When i type text, the system/view/caret is as long none until i refocus the area and reset the cursor manually to a specific position in the new typed text. After that i am able to insert text at the specified position in the new lines. Before this, the insertion will always happen behind the last character of my text. The problem for an automation i see is that when i refocus the area to update the /text i loose the position of the cursor, so it will be placed after my last character. The question is, how can i determine the cursor-position before refocussing the area to place the cursor at the right position after the focus? Any supporting ideas? Thorsten

 [8/11] from: g:santilli:tiscalinet:it at: 25-Feb-2002 18:18


At 12.16 25/02/02, Brett wrote:
>When you use the enter key, optionally typing some text after it, and then >click >the button - the area loses focus. I would like to know why this is.
That's because there's an event function that checks (via face/dirty?) to see if the current focused field has been updated, and if so does the field action; you could remove that event-func if you don't need the feature, or just patch it to make it work better. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [9/11] from: brett:codeconscious at: 26-Feb-2002 21:36


Hi Thorsten, Romano & Gabriele, Thanks Romano & Gabriele for the replies. That explains why the insert point is lost after the enter key. 1) UNFOCUS sets system/view/caret to none. 2) The default event function calls UNFOCUS.
> The question is, how can i determine the cursor-position before > refocussing the area to place the cursor at the right position > after the focus?
The trick is finding the right time to do this. I've been thinking it would be nice to have a "leave the field event" anyway. So my strategy is to generate one - that is fire a new ON-UNFOCUS function on the face when UNFOCUS occurs. I prefer not to replace the delivered functionality. Here the "embrace and extend" strategy is useful :) So I save away the existing UNFOCUS function and call it from a new UNFOCUS function that calls the ON-UNFOCUS function. Putting this together yields the code included below. Unfortunately the solution suffers from blinking which dissappears for most inserts if you remove the setting of the "dirty?" flag. I posted this anyway because it is still probably useful. The user guide indicates that line-list should be set to none when there a large changes to the text. The on-unfocus function could be useful for other applications. I'm not sure that this strategy will be useful as part of a more general framework but hey, its a start. Regards, Brett. ; ; "Extend" UNFOCUS. Call a function on the face ; that is losing focus. ; if not value? 'unfocus-now [ set 'unfocus-now get 'unfocus unfocus: func ["Removes the current key event focus."] [ if all [ system/view/focal-face in system/view/focal-face 'on-unfocus ] [ system/view/focal-face/on-unfocus system/view/focal-face ] unfocus-now ] ] ; ; Uses the extended UNFOCUS shown above. ; The area (a) is defined with an ON-UNFOCUS function ; that will record where the caret is before focus is ; lost. The button makes use of this extra information ; when system/view/caret is undefined (the original ; face lost focus). view layout [ style area area with [ last-caret: none on-unfocus: func [face] [ face/last-caret: system/view/caret ] ] a: area button "Insert" [ if csr: any [ system/view/caret a/last-caret ] [ csr: insert csr "<inserted>" a/dirty?: true ; indicate modifications a/line-list: none ; if lots of text changed. ] if system/view/caret [ system/view/caret: csr ] show a ] ]

 [10/11] from: rotenca:telvia:it at: 26-Feb-2002 14:02


Hi Brett,
> ; > ; "Extend" UNFOCUS. Call a function on the face
<<quoted lines omitted: 12>>
> ] > ]
Only for knowledge, I want to remember that there is an undocumented feature (which has little to do with yours). It is the 'refocus field of a field/area face. It is called by the standard tex-edit func, when a tab is hit and the flags tabbed is high, it can be used to override the standard back-field and next-field: tab-char [ if flag-face? face tabbed [ either in face 'refocus [face/refocus event/shift] [ tmp2: either event/shift [back-field face] [next-field face] if flag-face? face hide swap-text action face face/data focus tmp2 ] exit ] insert-char face tab ] --- Ciao Romano

 [11/11] from: moeller_thorsten:gmx at: 27-Feb-2002 11:28


Hi Brett, Romano & Gabrielle, thanks for your help, solving the problem. I think i have to dig a little deeper in event-handling to be able to solve such problems on my own in the future as i am not so familiar with it now. Thorsten

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted