r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[View] discuss view related issues

Steeve
27-May-2010
[9949]
I used to filter them in my own insert-event-func handlers
Henrik
27-May-2010
[9950]
found a way to brute force it. not pretty, though...
Cyphre
28-May-2010
[9951]
IMO these 'unwanted' events are generated by the actual OS so I don't 
think we can do anything with this. But for example the 'move events 
on mouse click shouldn't hurt anything because the event/offset is 
still the same so your code should treat them as 'almost no-op'.
Henrik
28-May-2010
[9952]
Cyphre, I didn't get the 'down event at all, which is what confused 
me.
Cyphre
28-May-2010
[9953]
really? Under WinXP if I do 'mouse click' I'm getting this sequence:
down 58x47
up 58x47
move 58x47
Henrik
28-May-2010
[9954]
I'm not sure my setup was that simple (it's gone now).
Cyphre
28-May-2010
[9955]
I tested on this code:
insert-event-func f: func [f e][print [e/type e/offset] e]
view layout [box red]
remove-event-func :f
Anton
28-May-2010
[9956x2]
With the above code on Linux I see this:

move 77x78 ; Final move of mouse to a stop, then I wait a short time...
down 77x78 ; <- I click.
up 77x78 ; <- I release, and I wait...
move 77x79 ; I begin moving mouse again.
(That's using View 2.7.6.4.2)
Cyphre
28-May-2010
[9958]
Yes, so it looks windows is adding the 'move event after I release 
the button....seems like no big issue tome though.
Anton
28-May-2010
[9959]
If I remember correctly, Windows also inserts a 'move event before 
the 'down, doesn't it?
Cyphre
28-May-2010
[9960]
I don't see that behaviour on my system..only one additional 'move 
after 'up
Anton
28-May-2010
[9961]
Ok, probably my poor memory of it then.
Cyphre
28-May-2010
[9962]
but in both cases it shouldn't be a problem IMO. Those events just 
goes thru your handler without any real action and doesn't look like 
a performance hit at all.
DideC
1-Jun-2010
[9963x2]
By the way, the "no" real handling of rate in window detect  that 
Maxim let me understand why I was unable to slow down the "Splascreen" 
demo as it use the window feel, not a face feel.
...that Maxim point of ...
Henrik
3-Jun-2010
[9965x2]
is there any known way to make rebol spontaneously quit? I've run 
into a case where it just quits, when I focus a field in the VID 
Extension Kit, but I have no clue what does it, although I can reproduce 
it every time.
under OSX a segfault is produced.
Maxim
3-Jun-2010
[9967]
using the variable name 'Q  ...  honestly, it's happened to me.
Henrik
3-Jun-2010
[9968]
nope, this one really just quits. I've reassigned Q, QUIT, UNVIEW, 
everything.
Cyphre
3-Jun-2010
[9969]
I remember I have seen that in some recursion/stack overflow cases 
but just guessing here.
Maxim
3-Jun-2010
[9970]
some AGG blocks crash ... are you using AGG?
Henrik
3-Jun-2010
[9971]
no AGG
Maxim
3-Jun-2010
[9972]
are you using a popup?
Henrik
3-Jun-2010
[9973x2]
Cyphre, it's possible there is some recursion problem.
Maxim, no a VIEW window
Maxim
3-Jun-2010
[9975]
very strange. especially on a focus event.
Cyphre
3-Jun-2010
[9976]
this is one case of this 'feature':
a: does [if error? try [a][a]]
Maxim
3-Jun-2010
[9977]
are you using 'WAIT [ ] manually somewhere?
Henrik
3-Jun-2010
[9978x2]
maxim, not that I know of.
Cyphre, ok nice to know.
Maxim
3-Jun-2010
[9980]
did you check ram use?
Henrik
3-Jun-2010
[9981]
less than 10 megs. it happens very quickly.
Cyphre
3-Jun-2010
[9982]
Henrik, I bet you are calling FOCUS recursively or something like 
that.
Henrik
3-Jun-2010
[9983]
it's possible
Maxim
3-Jun-2010
[9984]
a print object statement can also cause the interpreter to bust its 
stack.
Henrik
3-Jun-2010
[9985x2]
I think I figured it out... I have created a pane of faces manually 
where one is focused. Then I decide to remove that pane and build 
a new one, and then focus a new face in that new pane. But my focus 
calls unfocus first and wants to perform a focal-face on a face that 
doesn't belong anywhere => crash.
wants to perform a SHOW on a focal-face
Robert
3-Jun-2010
[9987]
Shouldn't this be catched by the GC?
Cyphre
3-Jun-2010
[9988]
IMO Looks more like a View(text related) bug.
Henrik
3-Jun-2010
[9989x2]
well, the face that SHOW is trying to show remains in memory, possibly 
with a reference to a parent-face that no longer exists. what exactly 
makes SHOW go boom, I'm not sure.
fix is done by unfocusing before destroying the pane. interesting 
bug.
Endo
22-Jun-2010
[9991]
There is a strange auto-complete (tab key) problem on View 2.7.7 
console,
connection: context [a: 1 b: 2]
test: context [a: 1 b: 2]
when you type conn then press tab key it writes just "connected?"
but its ok for test. no auto complete for "usage" function also.
Henrik
22-Jun-2010
[9992]
I've found another tab-complete problem where an error is produced. 
Only seen it when running large apps though.
Endo
22-Jun-2010
[9993]
After loading RebGUI tab-complete gives error for undefined values 
also.
Anton
22-Jun-2010
[9994]
Endo, I see the error in View 2.7.6.4.2 as well.
>> connection: 1
then I type "connect" and press tab --> "connected?"
Andreas
22-Jun-2010
[9995]
there's a built-in function "connected?" which lexicographically 
sorts before "connection", so it's completed first
Anton
23-Jun-2010
[9996]
That's the bug. It's supposed to stop the completion after the last 
letter common to all the possibilities.
Izkata
23-Jun-2010
[9997]
And Rebol does that - try it with "con" and hit tab twice.  The bug 
is omitting user-defined words..
Maxim
23-Jun-2010
[9998]
possibly only does defined while in the console