FF.au3 (v0.6.0.1b-15) [End of life]

[mLipok]

@Danp2 I just make my first Pull Request on GitHub, I'm not sure I do it properly

 

[Danp2]

1 hour ago, mLipok said:

I just make my first Pull Request on GitHub, I'm not sure I do it properly

Ok... I'll take a look now.

[mLipok]

On 5.05.2017 at 10:00 PM, Danp2 said:

Since @Stilgar hasn't reappeared, I'm thinking about setting up a repo on Github to maintain it.

Did you review @Stilgar version and merge his progress to GitHub version ?

 

[mLipok]

is this intentional to return @error in this way :

Func _FFWindowClose($sSearch = "", $sSearchMode = "title")
    Local Const $sFuncName = "_FFWindowClose"

    If $sSearch = "" Then
        _FFCmd("window.close();")
        Return @error
    EndIf

 

[Danp2]

22 minutes ago, mLipok said:

Did you review @Stilgar version and merge his progress to GitHub version ?

Yes, but you're welcome to double check and make sure that I didn't miss anything.

[Danp2]

5 minutes ago, mLipok said:

is this intentional to return @error in this way :

Func _FFWindowClose($sSearch = "", $sSearchMode = "title")
    Local Const $sFuncName = "_FFWindowClose"

    If $sSearch = "" Then
        _FFCmd("window.close();")
        Return @error
    EndIf

 

Good question. Looks like _FFCmd will return $_FF_ERROR_RetValue when an error occurs, so it appears that the intent is to pass that up the chain to the calling routine.

[mLipok]

Please add note about GitHub repository in first post.
Please also add relevant note about this support topic to the README.md file on GitHub.
 

[Danp2]

Done

[mLipok]

Thanks.

[mLipok]

Added here:
https://www.autoitscript.com/wiki/User_Defined_Functions#Browsers

 

[Iczer]

There a discussion about encodings on previous page, so i wanted to ask :

if I get some html with $sHTMLsource = _FFReadHTML("html", 0) function, then:

- what actual encoding of $sHTMLsource, will it match "<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">"

- What I should use to convert $sHTMLsource from any (written in html header charset) to "UTF-16LE" (_WinAPI_MultiByteToWideChar() ? )

[mLipok]

This is good news for me (EDIT: and I hope for community users who use this UDF  ) - that you ask this question.
Thanks for this.

Could you provied any example of URL which is not working for you properly ?
This could be any not this one which you are trying to automate.
Just must show as simple snippet.

As you can read I was intent to make a internal solution (inside UDF ) to this problem, but we need more url examples and testers who could say if it work's properly on different encodings. This mean all test which we will do for yours URL I plan to do on my URL :   http://wolnelektury.pl/

btw.
We must to do testing example for several URL with different encoding and languages, to test if all new modyfication will work properly.

 

Edited May 24, 2017 by mLipok

[Danp2]

FWIW, I'm not yet convinced that this encoding solution should be built into the main UDF. Perhaps an addition to FFex.au3?

[mLipok]

29 minutes ago, Danp2 said:

I'm not yet convinced that this encoding solution should be built into the main UDF.

What are your contraindications ?

[Danp2]

@mLipok

First, I'm not sure that it isn't already working as designed.

Second, 

On 5/5/2017 at 0:27 PM, jchd said:

If MozRepl returns UTF8 in all cases (I mean regardless of the encoding declared by the website, MozRepl converts everything to UTF8 for output), then it's safe [and even mandatory] to convert outputs to UTF16-LE for proper processing with AutoIt.

If the cake is half-cooked (MozRepl doesn't always output UTF8 in all cases) then things are much, MUCH difficult to deal with properly.
Yet I'd be a bit surprised if there are "significant" websites not using UTF8 today.

we would need to analyze the MozRepl coding to see if it is consistently returning UTF8.

Third, all of this may be moot point with Firefox's pending move to WebExtensions.

https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/

[mLipok]

Maybe I will say once again what I meant earlier.
User of this UDF knows when the problem is and when it does not exist.
Why not to give to user the ability to define a converter that works inside this UDF, in such a way, where user by simple/single declaration of conversion function, should be able to handle the whole automation problem in such cases ?

As I said, the user of this UDF (programmer / scripter) should set the proper data conversion method but only if he needs it. The question of whether it is needed should be user defined.

I hope now my concept is understandable and acceptable.

Edited May 24, 2017 by mLipok

[jchd]

I'm only a lurker here: I don't program actually nor use FF for any automation, so my opinion is just thin air.

What I think is that regardless of the encoding use and declared by websites, the output provided to the AutoIt user must be directly useable inside the rest of his application(s). Else someone would need to regularly check the website declared encoding and modify applications accordingly. Instead, providing UTF16 strings in all cases would be the most reliable way.

That would need websites to declare the charset they use, as per specifications, and midware layer(s) ala MozRepl to behave consistently. Else all bets are off and applications using FF will need regular and painful maintenance.

[mLipok]

29 minutes ago, jchd said:

Else someone would need to regularly check the website declared encoding and modify applications accordingly. Instead, providing UTF16 strings in all cases would be the most reliable way.

Currently we do not have any solution.
I propose an situation when we change entire UDF to the way which will allow:

1. for now: only preset manually encoding to give user ability to fix this problem now
2. for future: provide an easy way to add automatically encoding recognition.

But as I said first step is to put "parser/convert" function into UDF which will process any kind of results before this result will be Returned out of function.

Having possibility to set "parser/converter" function we can check, work, improve this with other users.

 

[mLipok]

43 minutes ago, jchd said:

That would need websites to declare the charset they use, as per specifications, and midware layer(s) ala MozRepl to behave consistently. Else all bets are off and applications using FF will need regular and painful maintenance.

If the website does not correctly set the encoding option, then the user must still be able to customize the conversion method anyway.

 

EDIT:

Quote

Else all bets are off and applications using FF will need regular and painful maintenance.

This is called $$commercial$$ update  

 

Edited May 24, 2017 by mLipok

[jchd]

Again I don't have experience working with FF but one possible way would be to enclose the current API with a stub which will first grab the header (or simply grab the page) and extract charset. Then perform the actual processing and maybe temporarily solve the issue with most websites. Non-conformal ones may need an extraparameter to force an ad-hoc conversion.

I now leave it to you guys who actually use the thing.