Leaderboard

There is no need to apologize. We are all learners, and always will be. The only difference is, how long someone has been traveling this road . Also using code created by others is not an issue - that' s why this community exists. However, it is always a nice gesture to thank the originator (as you did). You could also use the heart-shaped icon in the lower right corner of a contribution (e.g. the one from @Nine) to leave a reaction. Aside : to the Forum.

@ProspektThere are ways to traverse up and down the DOM using xpath. To retrieve the parent TR element, you should be able to do this -- $sRowTask = _WD_FindElement($sSession, $_WD_LOCATOR_ByXPath, "//td[contains(text(),'入庫データ取込エラー対応')]/parent::node()") There are additional ways to achieve the same result. Here's another option -- $sRowTask = _WD_FindElement($sSession, $_WD_LOCATOR_ByXPath, "//tr[./td[contains(text(),'入庫データ取込エラー対応')]]")

I agree

Off topic... by definition any constraint requirement is frustrating Right. I didn't consider that So the code above from TheXman is absolutely adequate For the fun a little regex way #Include <Array.au3> $s = "stephan.williamson@yahoo.com" $pw = "123lia#abc" Local $cnt = 3, $ok = 1, $no = "" $r = Stringregexp($s, '(?=([^@.]{' & $cnt & '}))(?=.*@)', 3) ; if i.e. the dot is not allowed in pw ; _ArrayDisplay($r) For $i = 0 to UBound($r)-1 If StringInStr($pw, $r[$i]) Then $ok = 0 Exitloop EndIf Next Msgbox(0,"", $ok & @crlf & $r[$i])

I’m not sure that’s really a good idea, for a couple of reasons: 1) Users will find it frustrating. Consider an email like stephan.williamson@yahoo.com, where one would have step-over half the letters in the alphabet. 2) Passwords would be less secure because they would be easier to guess because the letters from the email could be skipped in brute force attempts. IMHO, correlation between username and email is precisely what the OP is trying to prevent here, and a negative correlation, if broad enough is really the same deal.

This one is tricky, and hard to handle - as TheXman pointed it out If you want to keep such a constraint may I suggest this : in the password, forbid any character which is present in the email before the @ sign This is strong enough and *much* easier to achieve The other requirements are simple