adaliabooks: Looks like you're most of the way there anyway.

To attach a button you just need to find somewhere on the page to add it and grab a reference to that element (forgive me, but I tend to use jQuery so need to look up the plain javascript stuff and it may not be 100% accurate) using

var div = document.getElementById('insertIdhere')

then create your link to click on (a button may be more appropriate, but I can never remember which is better)

var aTag = document.createElement('a');

and append that to the div

div.appendChild(aTag);

then just wrap your current code in a function and set the link to call it when you click it:

aTag.onclick = function() {};

As for passing it on to others to use, if they have something like TamperMonkey or GreaseMonkey you can just make a userscript (you just need to slap some headings on the top) and then host it somewhere like Gist (which I use for Fundamentals) and give them the link to install it.

If you're not using userscripts I'm not sure what alternatives there are.. I believe there is a way to save a javascript to your favourites (a Bookmarklet I think it's called) and just run it from your favourites menu.

adaliabooks: I'm having a bit of trouble with my script at the moment (as anyone following the thread may have noticed) and I wondered if anyone here might be able to shed some light on it...

It's an issue with manual sorting, I've eliminated most of the obvious possible issues and it seems to boil down to this:

When I sort an array of objects, duplicates are created in the array (this is bad for a number of reasons, but that isn't so important as why it's happening).
Even more puzzling, I can't recreate the error myself, but all the users who are testing for me can. The only difference I can see is library size (I only have 118 games whereas everyone else testing has between 300 and 1200), but my efforts to emulate a larger library haven't led to errors or duplicates either.

I've come across one mention of sorting an array in Java leading to duplicates if you don't properly implement the results for equal to, greater than or less than (or 0, 1 and -1) in your sort function but I think I've got that all right.

Here's the relevant sorting function copied to pastebin.
The full script is here, and the whole section of relevant code is between line 2643 and line 3133 (though a lot of the last functions in that group are more for moving things then the sorting and displaying).

So, any ideas as to what the issue is?

adaliabooks:

dtgreene: Just looking at it, I see something strange in the naturalCompare function:
You are passing, to replace(), a function that has a side effect. This is, in general, not a good idea because you don't know exactly how the function is used, and in particular, how many times it will be called. Unless there is a guarantee regarding the implementation (like there might me for something like "map"), it is generally not a good idea to do this.

Consider also the fact that there may be more matches than you expect.

Edit: One more thing: In situations like this, different implementations of the language might yield different results. Since the code appears to be JavaScript, try running it in different browsers.

mrkgnao: Remind me. Did you try removing the naturalCompare() function altogether and using the default Javascript compare instead?

Because, frankly, this function is a pure waste of time for GOG's library, as I believe there are no more than a handful of titles that are sorted differently with it (off the top of my head, I can think of only three: 11th Hour, 1849, 1954 Alcatraz, and even these will move by no more than a row or two).

toxicTom: I've switched to Visual Studio 2015 (from 2013) and I must say - I'm really impressed. I'm not a great fan of MS, but in regard to this IDE they are doing something right. Every new version has new really useful features.

mrkgnao: Could you offer some examples? BTW, I'm still using VS 2008 at work.

toxicTom: Well... I'm developing in C#, so that's my reference:
*snip - list of features*

Wishbone: Do you know if it can open solutions from previous versions without converting the *.sln file in the file system?

toxicTom: I don't know about versions earlier than 2013, but it doesn't convert solutions from that one. Instead it creates a folder ".vs" with it's own solution settings. Could be that it handles all older versions like this, but I currently have no way of checking.

Wishbone: Okay, because that's one of the things that have always annoyed me about VS. Here's the issue. My company maintains a lot of integration solutions for a lot of customers. These are saved in our central TFS repository, and they do not all use the same VS version. Now, when making new solutions for customers, occasionally we run into a scenario that we know we have dealt with before at another customer. Hence, we go and open that customer's solution to see how we solved it before. However, if that solution is from a previous version of VS, the *.sln file is converted to the new format as soon as it is opened, and is immediately locked for editing in TFS. This means that when you've looked at an older solution, you have to remember to manually roll back all changes, even though you haven't actively made any changes, or nobody else can edit the file.