Mailing list - Entries of 2005


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qftestJUI] name uniqueness and component visibility


  • Subject: Re: [qftestJUI] name uniqueness and component visibility
  • From: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: Sat, 09 Apr 2005 14:22:02 -0000

Hello Martin,

qftestJUI 1.04.3 will choose one component at random (if they have the
same class).

You can possibly use a NameResolver to disambiguate components, e.g.
by prefixing the name of the parent component. Please see the
extension API for details.

With qftestJUI 1.8 you can alternatively change the option "Name
override mode" to "Hierarchical reslution" but you'll lose some
flexibility compared to "Name overrides everything".

Best regards,
    Greg

Martin Elmer Jørgensen <mej@?.dk> writes:

> Thank you Greg, I appreciate you quick answer very much!
>
> I am trying to find out if we can relax our component naming
> convention to make it easier to work with for developers. I'm still
> talking about version 1.04.3.
>
> Let's say name overriding is turned on, and I have two components
> with the same name that have isShowing()==true simultaneously. What
> will happen - perhaps one of the following?
>
> 1) the algorithm chooses the first component found with the appropriate name
> 2) the algorithm finds all components with that name and chooses one of them based on the other criteria (geometry, feature, etc.)
> 3) an error occurs?
>
>
> Med venlig hilsen / Regards
> Martin Elmer Jørgensen
> Systems Engineer, MSc C.S.
>
> Systematic Software Engineering A/S
> Søren Frichs Vej 39, DK-8000 Aarhus C
> Tel.:   +45 8943 2184 (direct)
> Fax:   +45 8943 2020
> Web:  www.systematic.dk
>
> -----Original Message-----
> From: Gregor Schmid [mailto:Gregor.Schmid@?.de]
> Sent: 7. april 2005 22:22
> To: qftestJUI-list@?.de
> Cc: Martin Elmer Jørgensen
> Subject: Re: [qftestJUI] name uniqueness and component visibility
>
>
> Hello Martin,
>
> excellent question. I think few people have ever read that section in
> the manual or thought about component recognition that much.
>
> The answer to your questions is that neither 1) nor 2) is quite
> correct. qftestJUI determines visibility using the isShowing() method
> which is very close to 1), including the case of a tabbed pane.
> However, I recently learned that the analogy to 1) breaks down in case
> of a CardLayout where Java consideres all components to be showing,
> not just the topmost one that is visible to the human eye.
>
> There is no difference between standard recognition and name override
> as far as visibility is concerned.
>
> I hope I've answered your questions completely, if not, please ask
> again.
>
> Best regards,
>     Greg
>
> Martin Elmer Jørgensen <mej@?.dk> writes:
>
> >    Hello all
> >
> >
> >    I am studying section 18.2 of the QFtest manual (for version 1.04.3)
> >    to clarify the scope of the required component name uniqueness.
> >
> >
> >    QUESTION 1
> >
> >    Speaking of the standard recognition algorithm, at the end of
> >    paragraph 4, it says "Components that aren't visible are not
> >    considered." What kind of visibility is meant? Which of the following
> >    interpretations is correct?
> >
> >
> >    Uniqueness requires that
> >
> >    1)       all simultaneously (to the human eye) visible components in
> >    the same window on screen have different names
> >
> >    2)       in the same window, all components whose isVisible() method
> >    returns true have different names
> >
> >
> >    Say I have a tabbed pane with tabs A and B. On tab A there is a button
> >    with name "save" and on B there is a button with name "save". Since
> >    tab A and tab B will not be simultaneously visible to the human eye,
> >    according to interpretation 1), uniqueness is achieved even though the
> >    two buttons have the same name. But according to interpretation 2),
> >    uniqueness is not achieved, because isVisible() is true for both
> >    buttons.
> >
> >
> >    QUESTION 2
> >
> >    In the same section 18.2, speaking of the recognition algorithm used
> >    when "name overrides everything" is turned ON, the last paragraph ends
> >    with a sentence: "The prerequisite for using this method is that you
> >    can guarantee that if a name is set on a component, it is going to be
> >    unique among the simultaneously visible components of the same class
> >    in one window." This is the formulation that lead me to think of
> >    interpretation 1) above.
> >
> >
> >    Is there any difference in the significance of visibility between on
> >    one hand, using the standard recognition algorithm, and on the other
> >    hand, having "name overrides everything" turned on?
> >
> >    Med venlig hilsen / Regards
> >    Martin Elmer Jørgensen
> >    Systems Engineer, MSc C.S.
> >    Systematic Software Engineering A/S
> >    Søren Frichs Vej 39, DK-8000 Aarhus C
> >    Tel.:   +45 8943 2184 (direct)
> >    Fax:   +45 8943 2020
> >    Web:  [1]www.systematic.dk
--
Gregor Schmid                                Gregor.Schmid@?.de
Quality First Software GmbH                     http://www.qfs.de
Tulpenstr. 41                                Tel: +49 8171 919870
DE-82538 Geretsried                          Fax: +49 8171 919876



Videos Downloads Documentation Buy Free Trial