15 Jul
2013
15 Jul
'13
8:43 a.m.
maybe another solution would be to unplug the hand mouseclickstate before sending the
event and to replug it after.
something like:
--------
simulateClick
self activeHand forbidMultipleClickWhile: [
self simulateClickWith: MouseEvent redButton]
--------
it would be much more efficient.
I will make a try.
Alain
Le 14 juil. 2013 à 21:26, Alain Plantec <alain.plantec(a)univ-brest.fr> a écrit :
yep, caught.
and finally it is funny :)
It has something to do with #simulateClick.
In Rubric, MouseClickState is used to have a real doubleClick (whereas in TextMorph, the
editor handle click/doubleClick by itself and not with MouseClickState).
Mouse clickState mesures the time between two MouseDown and decide for a simple click if
the time is > than HandMorph doubleClickTime.
When several tests with simulateClick are runned, then depending on the state of the hand
MouseClickState, a simple click or a double click are triggered.
So it explains why when you run several tests some of then are failing.
But when you run a single test with a single simultateClick, then it doesn't fail.
the lesson is that mouseClickState should not be shared (instance var of the HandMorph).
or it should test the target morph and not only the time.
the workarround is to wait before any simulateClick, I've tried and it works.
change the simulateClick method as follow and all your Rubric related tests should be
green again.
--------
simulateClick
(Delay forMilliseconds: HandMorph doubleClickTime + 1) wait.
self simulateClickWith: MouseEvent redButton.
--------
Cheers
Alain
Le 13 juil. 2013 à 17:26, Tudor Girba <tudor(a)tudorgirba.com> a écrit :
Wow, thank you very much for looking into this.
Doru
On Jul 13, 2013, at 3:14 PM, Alain Plantec <alain.plantec(a)univ-brest.fr> wrote:
ok, I 've a track
With rubric, if a textArea do not have the focus but has a selection, then the first
click on it give it the focus but don't deselect.
In that case, one have to click to times to have the old TextMorph behavior.
So, depending on the goal of the test, one have to send simulateClick one time or two
times and not alway only one time.
I will dig more to really understand.
Le 13 juil. 2013 à 10:11, Alain Plantec <alain.plantec(a)univ-brest.fr> a écrit :
--
www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."
and if one add a #inspect send in a testMethod,
the results are the same with the TestRunner but differ
if one run them from Nautilus.
As an example, with:
-----
testEnteringTextInPort
| composite textMorph |
composite := GLMCompositePresentation new with: [ :a | a rubricText display: ''
].
window := composite openOn: 4.
textMorph := self find: RubScrolledTextMorph in: window.
textMorph simulateClick.
self assert: textMorph activeHand keyboardFocus = textMorph textArea.
self simulateKeyStrokes: 'hello'.
(composite pane port: #text) value asString inspect.
<-------------------------------- ** inspect added here **
self assert: (composite pane port: #text) value asString = 'hello'
----
by running tests from Nautilus, the inspect runs ok and the result string is
'hello'.
but now #testAcceptKeyCanBeOverriden turns yellow
by running test from the TestRunner, #testEnteringTextInPort and
#testPastingUpdatesTextPort stay yellow (as without the inspect)
and #testAcceptKeyCanBeOverriden is green
Alain
Le 2 juil. 2013 à 12:49, Tudor Girba <tudor(a)tudorgirba.com> a écrit :
> Thanks. I got the same problem and I do not know where to start from. It's really
strange.
>
> For those interested, the tests are in the GLMRubricTextMorphicTest class. If you run
all of them repeatedly, you get some errors. If you run them individually, you do not.
>
> Alain: do you happen to have an insight?
>
> Doru
>
>
> On Tue, Jul 2, 2013 at 11:53 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote:
> Hi guys.
>
> I hope that we can release 4.8 and move to Pharo 3.0 soon. I wanted to fix failing
tests and the only one is Rubric test. I was working with it for some time, and I have no
idea what's up. When you run tests separately they work fine, but when being run in a
suite some test fail and failures are inflicted by test order
>
> Maybe someone have ideas where to look at? UI maybe?
>
> Uko
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"