didn't tested it yet, but a few suggestions (from what I read in this thread). Please do not take all this in the wrong way, it is meant as positive criticism. So first of all, let me tell you that it is a nice idea to make a program for
. But...
date problem/reconizing dates:
First of all, I don't realy know why you read in the date though. It is of no use actually for the thing you want to do (calculating total chattime from a log)!. But anyways...
take a look at
http://www.msgplus.net/help_registry.php
quote:
HKCU\Software\Patchou\MsgPlus2\your@email.com\Preferences\LogHeadDateFormat
=> local specific!
=> Format of the timestamp written in the chat log headers (Session Start line). For more information about the tags you can use, click here.
In other words, use that registry key to obtain the correct format that is used in the logs. The actual names of months/days/etc can be obtained from the system with an API.
When the format is still different then it is declared in that registry key (can happen when the user changed that registrykey previously), you can (in some cases) still obtain the correct date if you scan that date-text for the proper elements (1 or 2 digits for the day, 4 digits for the year and a textstring for the month), enumerate all the words of the months for all the available languages in plus! (can easly be found on the web) and you have your complete auto-detection of the correct date. Add an errorchecking for wrong cases so you can still obtain the correct format* and it is almost fool-proof.
Also, provide a way to the user to choose the above "automatic" option, and to enter his own format (when the date couldn't be verified or to process logs from other people maybe or whatever).
*When the registrykey defines "dd/MM" but the actually text in a log is "MM/dd", you can see the difference and what is what if one of the numbers is higher then 12 for obvious reasons...
Unicode
Support Unicode. This is vital in any Plus! related application!
Clock
I didn't tested it yet, so this might be trivial:
* What happens when the log contains times passing midnight?
*
quote:
Originally posted by j.g.allen
It supports 24 hr clocks and US/UK Dates
Make sure it also supports 12hr clocks. Same applies here as with the date: use the registrykey to determine the clock settings and/or the system default notation. Also, a 24h clock can be reconized if hours are >12. Also, it would be nice if the user can define the clock-type before processing the logs (just as with the "date-problem").
*
quote:
Originally posted by j.g.allen
quote:
Originally posted by jacoblo33
.--------------------------------------------------------------------.
| Session Start: 05 February 2005 |
| Participants: |
| Jacob (aa@hotmail.se) |
| Anna (test@hotmail.com) |
.--------------------------------------------------------------------.
My "test" file only consists of that text...
Any idea what else it could be?
No idea soz, it works with the properly generated files.
He's missing the daytext, although this shouldn't be an issue...
So, it also means that your code is (messy?)/faulty; you shouldn't take in account any text before the actual date, thus including the word for the day... or... you should use the method I described above (of course this can also include the discarding of the daytext as it is of no use).
eg: if you can use regular expressions, it would be a good and very quick way in grabbing the part of the line that you need while autoamtically ignoring all the rest.
Processingquote:
Originally posted by j.g.allen
You might need a blank line at the bottom.
Why? I mean, how do you search for the timevalues??
Any line not starting with "[" should be disregarded...
And only when you encounter ".--------------------------------------------------------------------." there is a new session started. Any other line should be ignored.
Every line that you encounter which begins with "[" should be dealt with as the end of the conversation*. This also makes that improper saved logs (due to systemcrash or whatever) can still be read properly, even if the "["-line is the last line and even if there are 10 empty lines after it.
*Only the first line you encounter which starts with "[" after the second ".-----." line is a start for your timecalculation.
Do all this until you actualy reach the EOF-marker of the file, only then you have processed the whole file. If the last line you encounter is a "["-line ended with an EOF-marker, then that means that the file is ended and you shouldn't read any further.
Errors
quote:
Originally posted by j.g.allen
quote:
Originally posted by traxor
![[Image: attachment.php?pid=378325]](http://shoutbox.menthix.net/attachment.php?pid=378325)
whenever I try and use it and type in an email adress, I get this error (Type mismatch), any ideas why, I download the *.txt compatible version 
...
This works for MSG Plus chat logs in the english language only. Check the final line of the chat log and check that it there is only 1 blank line at the end and no more than that.
An "Type mismatch" occurs when you try to assign an integer to a string variable or something like that. This almost can't have anything to do with the type of files you read in. Text should be text (eg: don't read in integers, bytes, etc. (it works though, if you know what you're doing) but rather read it in as strings, only when you need to process the strings convert them to numbers (only if you're sure that you have read in a number of course, otherwise the conversion will result in number 0). And again, don't assign a numbervariable to a stringvariable or vice-versa or something of that kind)
Other stuff
quote:
Originally posted by j.g.allen
The all chat logs in 1 txt file program, shdn't be too long, having a few problems. Tends to not work with really big files
Don't read the file as a whole, read it/process it line per line. This is the easiest way/more efficient to program and there will be no limit on filesize.
GUI
Make the fileselect dialog much wider, it is realy (too) small
Test
You can test your program with the attached log. If it can cope with all the bits and pieces, then the reading-in and calculating should be ok
stats for the testlog:
session 1: +00:01:09
session 2: +00:00:16
session 3: disregard (not enough time values to process)
session 4: +25:53:21
-note1: it is very unlikely that you encounter this in 1 session (a +24h session), but it is possible though. But this example is just to show that you need to cope with times passing midnight.
-note2: Also note that if you encounter 2 "[00:00:00]"-lines after eachother, it should be interpreted as 2 lines entered at the same time and not with a period of 24h between them as this is very unlikely because of the first note (although it could happen <= and this also proofs that calculating the total chattime like this isn't always 100% correct (only in rare cases though)).
session 5: disregard (corrupted/interrupted session)
session 6: +00:01:09
session 7: disregard (corrupted session)
session 8: +00:05:32 ! (disregard last line as you don't know the complete and correct timevalue)
total chattime should be 26:01:27 (in a total of 5 sessions)
/ 
Attachment: 
