|
That is some really scary code.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
The third one is especially sublime -- just return null no matter what.
I think the compiler should detect the proportion of your methods that are static and if it is higher than say 2%, should issue an error "You are not fit to be programming. Please step away from the computer."
|
|
|
|
|
Oh, that was great days...
Private Sub Command16_Click()
Open asc & "Read" & File2.FileName For Input As #1
Line Input #1, dat
Line Input #1, doo
Line Input #1, od
Line Input #1, temat
Close
Form2.Text1 = "Answer - " & od
Form2.Text2 = doo
Form2.Text3 = "Answer - " & temat
Form2.Text4 = "This is an answer to a message received in " & dat & "."
Form2.Show
End Sub
Private Sub Command6_Click()
Form4.Show
End Sub
Private Sub Command7_Click()
Frame1.Visible = True
Frame2.Visible = False
Frame3.Visible = False
Frame4.Visible = False
File1.Refresh
End Sub
Private Sub Command8_Click()
Frame1.Visible = False
Frame2.Visible = True
Frame3.Visible = False
Frame4.Visible = False
File2.Refresh
End Sub
Private Sub Command9_Click()
Frame1.Visible = False
Frame2.Visible = False
Frame3.Visible = True
Frame4.Visible = False
File3.Refresh
End Sub
Private Sub File1_DblClick()
If File1.ListIndex = -1 Then Exit Sub
sws = File1
Form3.Show
End Sub
Private Sub Form_Load()
On Error GoTo 1
Label5 = "Welcome, it's " & Format$(Now, "long date") & ", time" & Time$
ChDir App.Path
asc = App.Path & "\"
Label4 = asc & "user.ini"
Command7.Picture = LoadPicture(asc & "unr.ico")
Command8.Picture = LoadPicture(asc & "read.ico")
Command9.Picture = LoadPicture(asc & "deleted.ico")
Command10.Picture = LoadPicture(asc & "user.ico")
If Len(App.Path) = 3 Then asc = App.Path
Close
On Error GoTo 6
7:
Load Form8
Open asc & "InLookcon.ini" For Input As #1
Line Input #1, d1
Line Input #1, d2
Line Input #1, d3
Close #1
File1.Path = d1
If d2 = "ask" Then
If File1.ListCount = 0 Then
X = MsgBox("There are no new messages. Do you want to start InLook?", 32 + 4)
If Not X = 6 Then End
End If
ElseIf d2 = "norun" Then
End
End If
Label1 = d1
zapis = d3
On Error Resume Next
File2.Path = asc & "Read"
If Err > 0 Then
MkDir asc & "Read"
Err = 0
End If
File2.Path = asc & "Read"
Label2 = File2.Path
File3.Path = asc & "Deleted"
If Err > 0 Then
MkDir asc & "Deleted"
Err = 0
End If
File3.Path = asc & "Deleted"
Label3 = File3.Path
On Error GoTo 2
4:
Open asc & "user.ini" For Input As #1
3:
If Not EOF(1) Then
Line Input #1, a
List1.AddItem a
GoTo 3
End If
Close
Open asc & "usop.ini" For Input As #1
Line Input #1, opu
opus = opu
Close
Exit Sub
1:
MsgBox "Error. Required files are missing I suppose. Run ''Repair.exe''!", 0 + 16
End
Resume
2:
Close
Open asc & "user.ini" For Output As #1
Print #1, "Error occured: users was reset."
Close
GoTo 6
Resume
6:
Open asc & "opwp.ini" For Output As #1
Print #1, "1"
Close #1
GoTo 7
End Sub
...
Greetings - Jacek
|
|
|
|
|
I just love the error message "Required files are missing I suppose."
It let's the user know just what you think about error checking!
I take it this was a very early example of your craft?
I hope like hell this was a very early example of your craft?
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
OriginalGriff wrote: I hope like hell this was a very early example of your craft?
Yes it is a very early code. There have been a lot of OOP education later (that time I didn't even know classses and methods -- that's why everything was put in event handlers which were generated by "double clicking" in designer).
Greetings - Jacek
|
|
|
|
|
And we hope you have adopted more meaningful method naming habits. Not that "Command1_click" isn't a lovely name...
|
|
|
|
|
That time I didn't know that method/control names can be changed.
Greetings - Jacek
|
|
|
|
|
In that case, you must have been thinking "What a stupid system where everything has to be named Command[digit]_click "
|
|
|
|
|
|
looooooooooooooooooooooooooooool
Oh my god!!! Two questions come to my mind: How many times did you come and go from designer view to code view and vice versa? How many mouses did you wreck?
|
|
|
|
|
Check to see if the day defined by "year", "mon" and "day" is between dtStart and dtEnd:
if (year >= dtStart.Year && year <= dtEnd.Year &&
mon >= dtStart.Month && mon <= dtEnd.Month &&
day >= dtStart.Day && day <= dtEnd.Day)
{
ok = true;
}
else
{
ok = false;
}
He said, "Boy I'm just old and lonely,
But thank you for your concern,
Here's wishing you a Happy New Year."
I wished him one back in return.
|
|
|
|
|
Ah, a false false generator in disguise.
|
|
|
|
|
On a previous job, we had a small bug in a date validation routine... it was supposed to ensure that the date (year and month) was in the future. It checked the year, if it was greater than this year it returned true, if it was the same year it checked the month*. We encountered some data with a future year and a month of zero...
* Further details omitted for brevity.
|
|
|
|
|
I have far too much legacy code that does not check for data being in a valid range.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Hm. When setting dtStart to Dec 31, 2000 and dtEnd to Jan 1, 2100, there seems to be no date in this century which is ok. In case that there was nobody whom that guy wanted to date, that does not matter either.
|
|
|
|
|
An example of how the World SHOULD work...
|
|
|
|
|
At first glance I thought it was just an awkward way to do it, as in why not just create a date from the MDY, then compare. Then I saw the real problem...
|
|
|
|
|
same happened to me, I just couldn't see what was wrong
|
|
|
|
|
in order to fix the bugs, you could write:
ok=!(year<dtStart.Year||(year==dtStart.Year&&(month<dtStart.Month||(month==dtStart.Month&&day<dtStart.Day)))||
year>dtEnd.Year||(year==dtEnd.Year&&(month>dtEnd.Month||(month==dtEnd.Month&&day>dtEnd.Day))))
which still sits in the right forum.
|
|
|
|
|
Minor correction. Try:
ok=!(year<dtStart.Year||(year==dtStart.Year&&(month<dtStart.Month||(year==dtStart.Year&&month==dtStart.Month&&day<dtStart.Day)))||
year>dtEnd.Year||(year==dtEnd.Year&&(month>dtEnd.Month||(year==dtStart.Year&&month==dtEnd.Month&&day>dtEnd.Day))))
Else you'll end up with 'valid' dates that are well within the month/date bracket, but in the wrong year(s)!
hth
|
|
|
|
|
I disagree.
|
|
|
|
|
Or (in no particular language):
long ymd = (year * 12 + month) * 31 + day
bool ok = ymd >= (dtStart.Year * 12 + dtStart.Month) * 31 + dtStart.Day
&& ymd <= (dtEnd.Year * 12 + dtEnd.Month) * 31 + dtEnd.Day
This is still in the right forum as it permits 31st Nov and 33rd Feb and 0th May, -9th day of the 17th month etc. without fixing them properly; but valid dates work.
An even more horrible way with similar failings, but much faster would be (using << as a shift left logical operator and | as a bitwise OR):
long ymd = year << 9 | month << 5 | day
bool ok = ymd >= (dtStart.Year << 9 | dtStart.Month << 5 | dtStart.Day)
&& ymd <= (dtEnd.Year << 9 | dtEnd.Month << 5 | dtEnd.Day) This assumes less than 32 days per month (2^5) and less than 16 months per year (2^4). The year << 9 bits are year * 32 * 16 . So 33rd Feb and -9th day of the 17th month would be somewhat disasterous.
|
|
|
|
|
the shifting way is what I would actually do when DateTime were not available; with a little optimization:
int ymd = (((year<<4)+month)<<5)+day;
eyc.
IMO it is the cheapest mapping from dates to integers that supports chronological ordering. I do add parentheses, for readability if nothing else.
|
|
|
|
|
DateTime dt = new DateTime(year, month, day);
return (dt <= dtEnd & dt >= dtStart);
How about this one?
Enclosing it in try catch will cop with invalid dates too.
|
|
|
|
|
Sadly, I've written code like that.
Marc
|
|
|
|