Mailingliste - Einträge 2017

List Icon
Archiv Mailingliste

2019 bis Juli 2022  |  2018  | 2017 | 2016 | 2015 | 2014 | 2013

Die Mailingliste ist seit Juli 2022 geschlossen, dient aber weiterhin als Informationsarchiv zu QF-Test.
Wenn Sie aber über Neuerungen zu QF-Test informiert bleiben wollen, können Sie einfach unseren
Newsletter abonnieren

Um aktuell die Informationen zu jeder Release - auch Minor Releases - zu bekommen, können Sie den
RSS-Feed abonnieren oder uns in sozialen Medien folgen.
Alternativ bietet QF-Test auch selbst eine Versionsinformation an.

Eine weitere Informationsquelle ist unser Blog, in dem es aktuelle Beiträge zu allgemeinen Themen, zur Firma QFS und auch diverse "How-Tos" gibt:
Blog abonnieren

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

Re: [QF-Test] Interworking between 'waitForComponent', rc.getComponent and rc.getOverrideElement

  • Subject: Re: [QF-Test] Interworking between 'waitForComponent', rc.getComponent and rc.getOverrideElement
  • From: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: Wed, 22 Feb 2017 09:27:29 +0100
  • Delivered-to: qftest-list@?.net
Hello Bernhard,

that's a very good question.

The problem is that rc.getComponent has a 0 timeout because it blocks
the event dispatch thread. This means that you have to run
'WaitForComponent' first so that you can be sure to pick up the
correct component in rc.getComponent. Unfortunately rc.getComponent
then incurs the same overhead again.

We'll see about introducing a doctag to the WaitForComponent node that
puts the resulting component directly into rc.overrideElement. That
should be preferable to using a WaitForComponent plus a script node
even when the overhead is minimal. 

Best regards,
    Greg

Bernhard Schmitt <bernhard.schmitt@?.de> writes:

> Hello,
>
> I have a short technical question. Consider a web application with a component which is not easy to recognize and
> which takes a while until QF-Test has mapped it to its internal component.
>
> Our purpose is, to cache such a component with rc.overrideElement(), so that the time expensive recognition happens
> only one time.
>
> So the question is, what happens inbetween  'WaitForComponent' and rc.getElement, and rc.getOverrideElement().
>
> 1.       When WaitForComponent(id) succeeds, is it certain that the web component is accesible and I can immediatly
> cache it with rc.getOverrideElement(id)
>
> 2.       When I call rc.getComponent(„id“) after WaitForComponent(id) succeeds, ist the component recognized again
> with the same time effort as before?
>
> BR
>
> Bernhard

-- 
Gregor Schmid

E: gregor.schmid@?.de
T: +49 8171 38648-11
F: +49 8171 38648-16

Quality First Software GmbH | www.qfs.de
Tulpenstr. 41 | 82538 Geretsried | Germany
GF Gregor Schmid, Dr. Martina Schmid, Karlheinz Kellerer
HRB München 140833

Wir verwenden Cookies zur anonymisierten Auswertung Ihres Besuchs auf unserer Webseite durch »Matomo«. Dafür benötigen wir Ihr Einverständnis, welches für zwölf Monate gilt. Ein Widerruf bzw. Opt-out ist jederzeit auf unser Datenschutz-Seite möglich.

akzeptieren
konfigurieren
Cookie-Konfiguration

1. Funktionale Cookies

Wir verwenden funktionale Cookies, um die Basisfunktionalität der Webseite zu gewährleisten.

2. Performance und Statistik Cookies

Wir verwenden Matomo zur Analyse und Optimierung unserer Webseite. Cookies erlauben eine anonyme Erfassung der Informationen und helfen uns, Ihnen einen benutzerfreundlichen Besuch unserer Webseite zu bieten.

Auswahl speichern

Cookie details