xPath из HtmlElement (обратное действие)

[Iv1]

Как из HtmlElement получить его уникальный xPath назад?

Вот типовой код по поиску he (HtmlElement) определенного элемента
string xPath = "//a[contains(text(), 'Какая-то ссылка')]";
HtmlElement he = instance.ActiveTab.FindElementByXPath(xPath, 0);

Проблема такая, что если страница была перегружена или какой-то другой неведомый глюк, то элемент как he (HtmlElement) может уже не существовать, но при этом по xPath искаться.

Усугубляется это тем, что даже в стандартные функции как раз передается сам he (HtmlElement).

В общем.
Надо какой-то механизм как найти тот же элемент на странице, у которого he (HtmlElement) поломался.

 

[RoyalBank]

Перед обращением к элементу проверяй его на isNull

 

[Iv1]

Перед обращением к элементу проверяй его на isNull

Это очевидно что элемент может быть не действительный.
Надо какой-то механизм, сделать действительным.
Т.е. на момент обращения к странице - он 100% действительный, но при обновлении страницы он может ломаться. Хотя если искать по старому xPath - то все прекрасно ищется.

Вот и хочется придумать механизм как из he (HtmlElement) сделать уникальный xPath, и, если he (HtmlElement) сломается, переопределить его вновь.

Это еще более актуально, когда в owncode делаешь, где окружение попроще.

 

[Маломальский]

Это очевидно что элемент может быть не действительный.
Надо какой-то механизм, сделать действительным.
Т.е. на момент обращения к странице - он 100% действительный, но при обновлении страницы он может ломаться. Хотя если искать по старому xPath - то все прекрасно ищется.

Вот и хочется придумать механизм как из he (HtmlElement) сделать уникальный xPath, и, если he (HtmlElement) сломается, переопределить его вновь.

Это еще более актуально, когда в owncode делаешь, где окружение попроще.

Возможно, вам нужно 1) дождаться элемент в цикле, в котором 2) предусмотреть логику поиска 2 элемента на случай если нет элемента 1 или дальнейшая логика.

Перед обращением к элементу проверяй его на isNull

Приветствую, помните, мы обсуждали тему, как я понял IsVoid это обертка над he.ZP_ID.

 

[RoyalBank]

Приветствую, помните, мы обсуждали тему, как я понял IsVoid это обертка над he.ZP_ID.

Да, именно так описывался этот момент.

 

[Iv1]

Возможно, вам нужно 1) дождаться элемент в цикле, в котором 2) предусмотреть логику поиска 2 элемента на случай если нет элемента 1 или дальнейшая логика.



Приветствую, помните, мы обсуждали тему, как я понял IsVoid это обертка над he.ZP_ID.

he.ZP_ID - я до конца не понял что это такое
и я как раз пишу функцию именно что универсальную, которая хрен по скольки параметрам чекает валидность страницы после загрузки. И вот есть нюанс такой как выше...
А универсальная функция должна быть на то и универсальная, чтобы к конкретным элементам не привязываться.

 

[RoyalBank]

he.ZP_ID - я до конца не понял что это такое

Если элемент был на странице, но затем был удален, то проверка IsNull покажет это в момент проверки.

 

[Iv1]

Если элемент был на странице, но затем был удален, то проверка IsNull покажет это в момент проверки.

то да. Начитавшись постов, что были приведены - понимание разницы пришло.

Но задача то в том, чтобы еще заново корректно найти. xPath то находит. Это сам he слетает.

 

[LaGir]

Но задача то в том, чтобы еще заново корректно найти. xPath то находит. Это сам he слетает.

А что именно некорректно происходит при повторном поиске?
Если элемент слетел по каким-то причинам, то нужно просто переопределять его ещё раз. Насколько помню старые сообщения админов на форуме, при вещах типа перезагрузки, DOM и все связанное со страницей слетают (что логично), и нужные элементы нужно переопределять/искать заново. У меня во всех важных местах подобные проверки, неправильных отработок на моей памяти вроде не было.
Если в коде, то что-то типа этого используем:

string xPath = "//a[contains(text(), 'Какая-то ссылка')]";
HtmlElement he = instance.ActiveTab.FindElementByXPath(xPath, 0);

// На этом этапе страница может сломаться, например
// ...

// Если "поломка" произошла (элемент пуст)
if (he.IsVoid)
{
    // Заново определяем/ищем его по тому же пути XPath
    he = instance.ActiveTab.FindElementByXPath(xPath, 0);
}

 

[luk911]

Сам he слетать не может, он либо есть, либо его нет, либо он находится, либо нет.
Я подозреваю что у вас с другим проблема, а именно с видимостью элемента.
Для отладки выводите атрибут he href в лог, если там не пусто, то он его находит. А вот что вы с этим элементом дальше пытаетесь делать это другой вопрос.

 

[Yuriy Zymlex]

Делайте цикл с паузой в 250 мс (меньше не стоит), это уже много раз обсуждалось, но ограничьте его в попытках.

Не понятна только цель всего этого изврата.

he.ZP_ID - я до конца не понял что это такое

В постере уникальный ID HtmlElement'а полученного с текущей страницы, используется для их сравнения.

 

[Phoenix78]

Сам элемент he , это структура которая привязывается к нужной странице во время поиска по xpath . При изменении/перезагрузки исходной страницы связь будет недействительна. Поэтому никаких способов восстановить слетевший he нет. только один и это повторный поиск элемента на странице.
И да.... в самом элементе he нет никаких записей как его нашли. есть только найденный ID и все. а найти элемент можно не только через xpath. поэтому обратная трансформация из he в xpath только через свою дополнительную функцию на подобие что в хроме.

и естественно автопуть будет вида //*[@id="top"]/div[3]/div/div/div/div[1]/div/div[2]/div[2]/ol/li[1]/div/div[2]/a и опять же при перезагрузки/изменении страницы может и не работать уже.

 

[Iv1]

Сам элемент he , это структура которая привязывается к нужной странице во время поиска по xpath . При изменении/перезагрузки исходной страницы связь будет недействительна. Поэтому никаких способов восстановить слетевший he нет. только один и это повторный поиск элемента на странице.
И да.... в самом элементе he нет никаких записей как его нашли. есть только найденный ID и все. а найти элемент можно не только через xpath. поэтому обратная трансформация из he в xpath только через свою дополнительную функцию на подобие что в хроме.
Посмотреть вложение 61518
и естественно автопуть будет вида //*[@id="top"]/div[3]/div/div/div/div[1]/div/div[2]/div[2]/ol/li[1]/div/div[2]/a и опять же при перезагрузки/изменении страницы может и не работать уже.

Вот на подобии функции как в хроме было бы и хорошо придумать как.
то, что она кривая и некрасивая - плевать. Она должна быть валидна очень ограниченное время и частный случай вполне подойдет.

 

[Iv1]

Не понятна только цель всего этого изврата.

Я же упоминал выше.
Пишу функцию, которая более или менее гарантирует то, что страница загрузилась и валидная после, например, клика по ссылке.
Т.е. все функции клика работают с he (HtmlElement) приходится с этими же данными работать, как входными. В некоторые функции я сразу передаю xPath - там явно легче и вообще без проблем даже. Но так не везде можно.
БЫВАЕТ ситуация, когда новая страница не загрузилась по какой-то причине, а старая страница по какой-то причине перегрузилась или как-то поломалась. Вот и ПОЛУЧАЕТСЯ что he уже не действителен, хотя по xPath все ищется прекрасно.
Напоминаю. Эту функция как раз для случаев когда все пошло не так, как надо и даже слегка через жепу. Потому ситуация очевидно что не типичные.

p.s. Кто-то реально считает что в зенке уже нет проблем с загрузкой вкладок? Стало лучше, не спорю, но не все.