[APPLICATION] History Reader

[Adultery]

Not a big deal (not even enough to make a glamorous page for it), but I wrote an app for snagging History.dat info while I was practicing writing my own parser. It's simple to use and quick as hell, and it was fun to make (what's a couple hours on a Saturday anyhow?) So...

For the console app (historysearcher.exe):

Example CL: "History Reader.exe" -rom punchout -history "C:\History Reader\DATs\history.dat" -mameinfo "C:\History Reader\DATs\mameinfo.dat"

-rom

-romname

-romfile

The name of the rom to get the info for.

-history

-historypath

-historyfile

The location of your History.dat file. (If you don't specify a path the app will look in the application's root folder).

-mameinfo

-mameinfopath

-mameinfofile

The location of your MameInfo.dat file. (If you don't specify a path the app will look in the application's root folder).

You can just code your program to redirect the standard output if one was so inclined to do so.

Otherwise this is probably useless to ya unless you wanted to look around at your MAME game history...

I also made a GUI for this little bugger and I thought it turned out kinda sexy! (History Searcher GUI.exe):

The GUI has a file browsing option and can save the output to a text file as well.

Not sure what else I can really say about it. Maybe someone might find it useful. I mean, ya just never know!

*UPDATED 9/22/12*

• (Console) Updates to code as per Ben's suggestions
  
• (GUI) Likewise.
  

*UPDATED 9/16/12*

• (Console) Added MAMEINFO.DAT parsing
  
• (GUI) Added options for MAMEINFO.DAT
  
• (GUI) Cosmetic updates
  

History Reader.rar

[nullPointer]

Always amazed by your skills and the amazing level of output you're able to produce Adultery! Keep up the great work man.

[AlphaUMi]

I could quote null's words from "Always" to "man"... Great work Adultery!!!

[KRC]

Great work Adultery !

[Adultery]

*UPDATED 9/16/12*

• (Console) Added MAMEINFO.DAT parsing
  
• (GUI) Added options for MAMEINFO.DAT
  
• (GUI) Cosmetic updates
  

[headkaze]

Nice work Adultery. Just a few suggestions (you can take them or leave them).

- Don't use Directory.GetCurrentDirectory() because the current directory isn't necessarily the executable's folder. Use Path.GetDirectoryName(this.GetType().Assembly.Location) instead.

- Rather than creating a folder by appending strings use Path.Combine. Eg. Path.Combine(Path.GetDirectoryName(this.GetType().Assembly.Location, "history.dat"). If you ever run your code using Mono the folder separator for Windows is different on Linux based machines.

- For the same reason use Environment.NewLine instead of "\r\n".

- Rather than use StreamReader consider the helper class File. Eg. File.ReadAllLines().

- Rather than using "goto" you can use "break" to break out of a loop or "continue" to continue a loop (VB.NET equivalents would be Exit For/Exit While/Exit Do and Continue)

[Adultery]

I do love suggestions! Its the only way to learn! In RE:

I actually use Application.StartupPath most times unless its for a process Working Directory, in which case I use Path.GetDirectoryName

Most of the time I do use Path.Combine, but not always. I will now though as you make a great point there.

I usually use vbcrlf for a new line.

I used StramReader.ReadLine since I thought it may be faster than parsing the whole file after loading it.

On that note I was using Exit While (Do While SR.Peek() <> -1) to break the loop.

[Adultery]

I took most of your suggestions Ben, thanks,

*UPDATED 9/22/12*

• (Console) Updates to code as per Ben's suggestions
  
• (GUI) Likewise.
  

[headkaze]

I do love suggestions! Its the only way to learn! In RE:

I'm glad to hear that, It certainly helps to get into good habits

I actually use Application.StartupPath most times unless its for a process Working Directory, in which case I use Path.GetDirectoryName

Yes Application.StartupPath is definately the way to go for a Form based application. For dll's (GX plugins) and console apps the one I mentioned works well.

Most of the time I do use Path.Combine, but not always. I will now though as you make a great point there.

It's a good habit to get into.

I usually use vbcrlf for a new line.

That is defined as "\r\n" but on some systems it will be "\n" or "\r". Environment.NewLine maintains compatibily for these systems.

I used StramReader.ReadLine since I thought it may be faster than parsing the whole file after loading it.

It's quicker to read everything into memory and then processing the data. I just like how the File class makes it nice and easy. For creating a text file I use a List<string> textList then textList.Add() to it. You don't even need to add the newline characters. Then just call File.WriteAllLines(textList.ToArray()).

On that note I was using Exit While (Do While SR.Peek() <> -1) to break the loop.

That's interesting as .NET Reflector (which I used to peek at your code) converts it to a goto statement. But the Exit While is definately the preferred way despite what it compiles to.

[Adultery]

I think the reason for that is it's implied. I don't use any continue for or goto code at all, maybe the VB environment adds this for me?