2018 up to now | 2017 | 2016 | 2015 | 2014 | 2013 | 2012

Mailing List - Entries from 2018 up to now

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000099">
    Hi Gregor,<br>
    <br>
    sorry to come back on this old thread, but I am experiencing some
    weird things with my item resolvers.<br>
    <br>
    I have an OpenGL canvas and I have a custom item resolver to
    recognize what happens inside it.<br>
    When I record a click onto one of these items, the mouse event and
    the item is properly recognized, and the X and Y are correct
    (relatively to the origin of the item). When I replay this event (as
    a hard event to see what is going on), the mouse pointer correctly
    moves at the (X,Y) relatively to the item.<br>
    <br>
    If from the mouse event I delete the X and Y values and replay this
    event, the mouse cursor properly moves to (5, vertical center).<br>
    So far, so good.<br>
    <br>
    Now if in the X and Y I put (1,1), replaying the event moves the
    mouse to (1,1) within this item, and not (5,vertical center) as I
    expect.<br>
    It however works well for any other native Java component.<br>
    <br>
    You said "<font size="2"> QF-Test should automatically treat events
      to (1,1) identically to events without coordinates __if__ the
      target component or item does abstract from coordinates when
      recording"</font>. So I guess the bit I miss is this abstraction
    of coordinates.<br>
    <br>
    I tried to play with the repositionMouseEvent function of the
    ItemResolver interface. I can make QFTest record a mouse click at
    (1,1) inside the item whatever the exact location the click occurred
    within this item, but the replay will still go at (1,1), not
    (5,vertical center).<br>
    <br>
    So I actually have two questions (one single answer would make me
    happy):<br>
        - what is the trick with the repositionMouseEvent to make the
    recording have blank X and Y? (so the replay will aim at the center
    of the item)<br>
        - why recording (1,1) does not make QFTest replay with
    (5,vertical center)? Am I missing something in the ItemResolver
    interface?<br>
    <br>
    Thanks for your help!<br>
    <div class="moz-signature">
      <p style="font-family: arial; font-size: 12px; color: rgb(128,
        128, 128);"><b style="color: rgb(0, 0, 255);">Denis GAUTHIER</b></p>
      <br>
    </div>
    <br>
    On 28/04/2011 6:06 PM, Gregor Schmid wrote:
    <blockquote cite="mid:4cmxjaer5z.fsf@qfs.de" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="MS Exchange Server version
        08.02.0254.000">
      <title>Re: [QF-Test] Replay recorded sequence does not work with
        coordinate (1, 1)</title>
      <!-- Converted from text/plain format -->
      <p><font size="2">Hello Peter,<br>
          <br>
          the original problem you describe, i.e. components not
          reacting<br>
          reliably to clicks on (1,1), was one of the main reasons why
          we<br>
          changed to targeting the center of a component or item
          instead.<br>
          <br>
          The later change to (5,vertical center) was due to the fact
          that some<br>
          items don't report their geometry correctly so a compromise
          was<br>
          needed. There are no known problems with this latest variant.<br>
          <br>
          Regarding your question about what to do with existing events<br>
          targeting (1,1): Please give QF-Test version 3.4M2 a try.
          QF-Test<br>
          should automatically treat events to (1,1) identically to
          events<br>
          without coordinates __if__ the target component or item does
          abstract<br>
          from coordinates when recording. So ideally things should work
          out of<br>
          the box.<br>
          <br>
          Best regards,<br>
              Greg<br>
          <br>
          Peter Fuerholz <a class="moz-txt-link-rfc2396E" href="mailto:Peter.Fuerholz@ascom.ch"><Peter.Fuerholz@ascom.ch></a> writes:<br>
          <br>
          > Hi,<br>
          ><br>
          > our current set up is like this:<br>
          > - QF-Test V. 3.2.2<br>
          > - 'Set coordinates of mouse events to (1,1) where
          possible' (Koordinaten von Mausevents auf (1,1)<br>
          > setzen wo möglich) is checked<br>
          ><br>
          > Due to changes in our user interface classes (I presume
          it is the change to JIDE V. 3.0.0) we are<br>
          > no longer able to replay recorded sequences after
          recording. The issue is, that with the<br>
          > coordinate set to 1,1 a table cell does not change from
          rendering in the editing status. Thus, the<br>
          > editing component, e.g. a combo box does not appear and
          cannot be found. Error message: "Die<br>
          > Zielkomponente 'AbstractComboBox.arrowButton' konnte
          nicht gefunden werden."<br>
          ><br>
          > As I found out I could update the appropriate mouse
          clicks from 1,1 to e.g. 5,5 which would solve<br>
          > the problem. Nevertheless, this would be very cumbersome.<br>
          ><br>
          > While looking through the latest bugfixes I saw that new
          QF-Test versions had some improvements in<br>
          > this area:<br>
          > - Version 3.3.0 changed setting from coordinate (1,1) to
          <empty>. QF-Test interprets <empty> as<br>
          > mouse click centered over the component.<br>
          > - Under 'Version 3.4M1 - February 3, 2011', 'Bugs fixed:'
          there is written:<br>
          > "When replaying mouse events without coordinates on
          items, QF-Test no longer targets the center of<br>
          > the item, but the position 5 pixels from the left,
          vertically centered. Apparently some events are<br>
          > sensitive to whether the click hits the text of an item
          and not just its bounding box, so short<br>
          > items in a broad column could cause problems."<br>
          ><br>
          > (With V. 3.2.2 it is not possible, that have the
          x/y-coordinates empty.)<br>
          > <br>
          > My question is now, how could I solve my problem without
          manually changing all mouse event<br>
          > coordinates? Just updating to the latest QF-Test probably
          does not solve the problem, does it?<br>
          > (The 1,1 coordinate in the mouse events do still
          exist...)<br>
          > Maybe the problem could be solved by an XSL-template
          replacing all 1,1 (mouse-event) coordinates<br>
          > with say 5,5 ? (Any experiences ?)<br>
          ><br>
          > Yours,<br>
          > Peter Fürholz<br>
          <br>
          --<br>
          Gregor Schmid                               
          <a class="moz-txt-link-abbreviated" href="mailto:Gregor.Schmid@qfs.de">Gregor.Schmid@qfs.de</a><br>
          Quality First Software GmbH                     <a
            moz-do-not-send="true" href="http://www.qfs.de">http://www.qfs.de</a><br>
          Tulpenstr. 41                               Tel: +49 8171
          38648-0<br>
          DE-82538 Geretsried                         Fax: +49 8171
          3864816<br>
          GF: Gregor Schmid, Karlheinz Kellerer          HRB München
          140833<br>
          <br>
          _______________________________________________<br>
          qftest-list mailing list<br>
          <a class="moz-txt-link-abbreviated" href="mailto:qftest-list@qfs.de">qftest-list@qfs.de</a><br>
          <a moz-do-not-send="true"
            href="http://www.qfs.de/mailman/listinfo/qftest-list">http://www.qfs.de/mailman/listinfo/qftest-list</a><br>
        </font>
      </p>
    </blockquote>
  
-------------------------------------------------------------------------
DISCLAIMER: This e-mail transmission and any documents, files and 
previous e-mail messages attached to it are private and confidential.  
They may contain proprietary or copyright material or information that 
is subject to legal professional privilege.  They are for the use of 
the intended recipient only.  Any unauthorised viewing, use, disclosure, 
copying, alteration, storage or distribution of, or reliance on, this 
message is strictly prohibited.  No part may be reproduced, adapted or 
transmitted without the written permission of the owner.  If you have 
received this transmission in error, or are not an authorised recipient, 
please immediately notify the sender by return email, delete this 
message and all copies from your e-mail system, and destroy any printed 
copies.  Receipt by anyone other than the intended recipient should not 
be deemed a waiver of any privilege or protection.  Thales Australia 
does not warrant or represent that this e-mail or any documents, files 
and previous e-mail messages attached are error or virus free.  

-------------------------------------------------------------------------
</body>
</html>