This is not for unbreak now priority..

@Tacsipacsi Give a screenshot of it.

Which wiki? What URL are you putting in?

In T166238#3471895, @Tacsipacsi wrote:

I think it's quite high priority bug as it makes impossible to use the software.

Which you system have?

I just opened AWB on Windows 7 (the dialog appears before the green loading window disappears), but the same error occurs on selecting any wiki.

Let's try this first:

1. Press windows button and R
   
2. then write %temp% and press enter
   
3. Then select all and delete all what can. What can not, on error click skip

In T166238#3471971, @Zoranzoki21 wrote:

Let's try this first:

1. Press windows button and R
   
2. then write %temp% and press enter
3. Then select all and delete all what can. What can not, on error click skip

That isn't going to help.

In T166238#3471933, @Tacsipacsi wrote:

I just opened AWB on Windows 7 (the dialog appears before the green loading window disappears), but the same error occurs on selecting any wiki.

Even the english wikipedia etc?

In T166238#3472007, @Reedy wrote:

In T166238#3471971, @Zoranzoki21 wrote:

Let's try this first:

1. Press windows button and R
   
2. then write %temp% and press enter
3. Then select all and delete all what can. What can not, on error click skip

That isn't going to help.

Me ever help when I have this problem.

In T166238#3472007, @Reedy wrote:

That isn't going to help.

Me neither.

Even the english wikipedia etc?

It occurs on all English and multilanguage projects (Wikiquote, Meta etc.), except the English Wikipedia. I think this is because when I close the wiki change dialog without changing the wiki (AWB sets the wiki automatically to enwiki upon failure), the buggy code doesn't run.

I'm guessing Input string was not in correct format is coming from something buggy inside AWB, or a string it's constructing is bad.

Unfortunately, the error message isn't very helpful as to working out wtf/where is wrong.

The fact no one else seems to be having the issue is weird too

I debugged a bit and pointed out that it occurred while processing the namespaces (WikiFunctions/SiteInfo.cs, line 200), at the first namespace (Media, -2). Then it came to my mind that I was playing with the minus sign in my Windows settings, so I changed it back from – (em dash) to - (hyphen). Surprise, surprise, it worked! So this line should be made culture-independent to avoid such errors. For example by using JSON—I don't know what JSON processing functions are there in C#, but the JSON response uses JSON numbers for namespace numbers, not strings, so they may be easier to process.

AFAIK there's not an int.parse() overload for culture-invariant

I'm not sure how what we get from the API is affected by the Windows settings though...

We're also using the XML output. Long term goals are to switch stuff to use JSON, but that's a lot more work :). We do use JSON for some of the stuff in SiteInfo already, where it's more self contained (

The API result is independent of Windows settings, so it always produces -2 (with a hyphen). The problem is that int.Parse() does depend on Windows settings, so it treats only –2 (with en dash) as a negative integer, and throws an error if the input uses hyphen. If you don't want to change this to JSON yet, maybe you could insert a try-catch and give feedback to the user, telling them this workaround.

For an issue affecting one person... I'm not sure it's worth a try catch. We can just use TryParse...

The question is how we try and resolve it programatically... Or if we even do.

Should we have to work around people changing random settings in Windows?

Oh, wait. We can do CultureInfo

https://msdn.microsoft.com/en-us/library/f56zcx39(v=vs.110).aspx

svn rev 12173, will pull it through to git

https://github.com/reedy/AutoWikiBrowser/commit/d13654cde2a11af5bb793627b3cfd56f13fe87b3