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>
    fair enough. Reimplementing a complete resolver would require a
    major effort on my side as well.<br>
    <br>
    Representing the hierarchy as path is a good idea and a fair
    compromise. I'll give it a go.<br>
    <br>
    Thanks for the feedback.<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><br>
        Software Integration - LORADS<br>
        <b>Air Operations</b></p>
      <p style="font-family: arial; font-size: 12px; color: rgb(128,
        128, 128);"><b style="color: rgb(0, 0, 255);">Thales Australia</b><br>
        Thales Australia Centre, WTC Northbank Wharf, Atrium Lobby
        Level,<br>
        Siddeley Street, Melbourne, VIC 3005, Australia<br>
        <b>Tel:</b> +61 3 8630 4407 | <b>Fax:</b> +61 3 9629 8433<br>
        <a href="mailto:denis.gauthier@thalesgroup.com.au">denis.gauthier@thalesgroup.com.au</a>
        | <a href="http://www.thalesgroup.com.au">www.thalesgroup.com.au</a></p>
    </div>
    <br>
    On 10/06/2011 5:50 AM, Gregor Schmid wrote:
    <blockquote cite="mid:33fwni238r.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] Create components through a resolver?</title>
      <!-- Converted from text/plain format -->
      <br>
      <p><font size="2">Hi Denis,<br>
          <br>
          excellent thinking. This idea has come up about a year ago in
          an<br>
          internal discussion about how better to handle GEF items
          without<br>
          requiring users to write ItemNameResolvers.<br>
          <br>
          Unfortunately it is very difficult to implement because the
          concept<br>
          falls between plain components and items and no matter which
          way we<br>
          implement it it is going to break a lot of existing code in
          QF-Test<br>
          that doesn't know how to deal with smart items.<br>
          <br>
          Still, the idea is good, so despite this being a major effort
          there is<br>
          a chance that this is going to be implemented at some time,
          perhaps<br>
          for QF-Test 4, but I'm not going to make any promises.<br>
          <br>
          However, regarding the hierarchical structure, you should take
          a look<br>
          at the GEF resolver that comes in qftest/jython/Lib/gef.py. It
          creates<br>
          hierarchical indexes as paths, similar to those for tree nodes
          and it<br>
          produces excellent results as long as it gets reasonably
          useful<br>
          partial item names from ItemNameResolvers along the path.<br>
          <br>
          Best regards,<br>
              Greg<br>
          <br>
          Denis Gauthier <a class="moz-txt-link-rfc2396E" href="mailto:denis.gauthier@thalesgroup.com.au"><denis.gauthier@thalesgroup.com.au></a>
          writes:<br>
          <br>
          > Dear fellow QFTest users,<br>
          ><br>
          > my application is mainly composed of an OpenGL canvas.<br>
          > I have implemented a custom itemResolver which allows
          QFTest to "see" what is going on inside this<br>
          > canvas.<br>
          > However this way of doing is showing some limitations,
          mainly due to the 2 index level constraint.<br>
          ><br>
          > To overcome this I was wondering if any extension API
          existed to have what is displayed in the<br>
          > canvas considered as Components by QFTest instead of
          Items.<br>
          > These 'items' are indeed very close to regular
          components: they have a class, a position, some<br>
          > features and even a name!<br>
          > A smart resolver would then make QFTest aware of the
          complete hierarchy of components within the<br>
          > canvas, down to any depth.<br>
          ><br>
          > Is this something that is possible (and has anyone done
          it)?<br>
          ><br>
          > Thanks for your feedback.<br>
          > --<br>
          ><br>
          > Denis GAUTHIER<br>
          ><br>
          >
          -------------------------------------------------------------------------
          DISCLAIMER: This e-mail<br>
          > transmission and any documents, files and previous e-mail
          messages attached to it are private and<br>
          > confidential. They may contain proprietary or copyright
          material or information that is subject to<br>
          > legal professional privilege. They are for the use of the
          intended recipient only. Any<br>
          > unauthorised viewing, use, disclosure, copying,
          alteration, storage or distribution of, or<br>
          > reliance on, this message is strictly prohibited. No part
          may be reproduced, adapted or<br>
          > transmitted without the written permission of the owner.
          If you have received this transmission in<br>
          > error, or are not an authorised recipient, please
          immediately notify the sender by return email,<br>
          > delete this message and all copies from your e-mail
          system, and destroy any printed copies.<br>
          > Receipt by anyone other than the intended recipient
          should not be deemed a waiver of any privilege<br>
          > or protection. Thales Australia does not warrant or
          represent that this e-mail or any documents,<br>
          > files and previous e-mail messages attached are error or
          virus free.<br>
          >
-------------------------------------------------------------------------<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>
        </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>