What am I missing about comparing Dates here?

[sherifffruitfly]

Hi all,

The following function is the ValueChanged handler for two
DateTimePicker thingies - allowing the user to specify a date range. I
don't understand why the following bug exists: when the first picker is
set later than the second, the messagebox pops up *twice* in
succession.

What's causing that? How can I achieve the (obvious) desired effect?

Thanks for any thoughts,

cdj
================
private void checkDates(ref DateTimePicker first, DateTimePicker
second)
{
if (first.Value.Date second.Value.Date)
{
MessageBox.Show("End date may not be earlier than start date.",
"Rates Aggregator");

//I would MUCH rather not allow the change to be made at all,
//but this will do for now.
first.Value = second.Value;
}
}

private void dateTimePickerStart_ValueChanged(object sender,
System.EventArgs e)
{
checkDates(ref dateTimePickerStart, dateTimePickerEnd);
}

[VJ]

You are changing the value again in valuechanged event, so it will fire
twice. Scary part is if you put the assignment outside the if (first.Value =
second.Value;
), it is a infinite loop.

VJ

"sherifffruitfly" <sh*************@gmail.comwrote in message
news:11*********************@f16g2000cwb.googlegro ups.com...

Hi all,

The following function is the ValueChanged handler for two
DateTimePicker thingies - allowing the user to specify a date range. I
don't understand why the following bug exists: when the first picker is
set later than the second, the messagebox pops up *twice* in
succession.

What's causing that? How can I achieve the (obvious) desired effect?

Thanks for any thoughts,

cdj
================
private void checkDates(ref DateTimePicker first, DateTimePicker
second)
{
if (first.Value.Date second.Value.Date)
{
MessageBox.Show("End date may not be earlier than start date.",
"Rates Aggregator");

//I would MUCH rather not allow the change to be made at all,
//but this will do for now.
first.Value = second.Value;
}
}

private void dateTimePickerStart_ValueChanged(object sender,
System.EventArgs e)
{
checkDates(ref dateTimePickerStart, dateTimePickerEnd);
}

[sherifffruitfly]

VJ wrote:

You are changing the value again in valuechanged event, so it will fire
twice.

(smacks forehead) Thanks!

Maybe it's just late in the day, but I'm not seeing offhand how to
achieve the effect I'm after. Perhaps a local counter variable in the
handler ("how many times have I been here?") would do the trick.

Is there some standard way to limit date entries in the way I'm after?
Thanks again for the logic lesson! lol

cdj

[VJ]

anytime. Please never feel bad, it happens to everybody.. that is why people
are here to help!

I would inherit and write my own DateTime class and have method to write the
checks/validations that I need.

VJ

"sherifffruitfly" <sh*************@gmail.comwrote in message
news:11**********************@h54g2000cwb.googlegr oups.com...

>
VJ wrote:

>You are changing the value again in valuechanged event, so it will fire
twice.

(smacks forehead) Thanks!

Maybe it's just late in the day, but I'm not seeing offhand how to
achieve the effect I'm after. Perhaps a local counter variable in the
handler ("how many times have I been here?") would do the trick.

Is there some standard way to limit date entries in the way I'm after?
Thanks again for the logic lesson! lol

cdj

[Jon Skeet [C# MVP]]

sherifffruitfly <sh*************@gmail.comwrote:

The following function is the ValueChanged handler for two
DateTimePicker thingies - allowing the user to specify a date range. I
don't understand why the following bug exists: when the first picker is
set later than the second, the messagebox pops up *twice* in
succession.

What's causing that? How can I achieve the (obvious) desired effect?

<snip>

I see your actual problem is fixed, but I'm concerned that you're
passing parameters by reference unnecessarily. That usually indicates a
lack of understanding of reference types or parameter passing.
Hopefully this link will help you:

http://www.pobox.com/~skeet/csharp/parameters.html

(Note that even though DateTime is a struct, DateTimePicker is a
class.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[sherifffruitfly]

Jon wrote:

I see your actual problem is fixed, but I'm concerned that you're
passing parameters by reference unnecessarily. That usually indicates a
lack of understanding of reference types or parameter passing.
Hopefully this link will help you:

http://www.pobox.com/~skeet/csharp/parameters.html

(Note that even though DateTime is a struct, DateTimePicker is a
class.)

Thanks Jon. I was doing that on purpose, actually. It occurred to me
that this was a place where it made sense (albeit trivial) to want to
actually change the input, rather than just computing with it. And
since I had never used ref/out variables before, I decided to go for
it.

In particular, using by-value variables, I would've had to specifically
*name* the control whose value I wanted to reset in the handler. I
thought this "coupling" was unneccesary, and if I passed by reference,
I could say "change the value of whatever the input was, where ever it
came from".

It's perfectly possible, of course, that I am suffering from numerous
confusions - thanks for the page!

cdj

[Jon Skeet [C# MVP]]

sherifffruitfly <sh*************@gmail.comwrote:

http://www.pobox.com/~skeet/csharp/parameters.html

(Note that even though DateTime is a struct, DateTimePicker is a
class.)

Thanks Jon. I was doing that on purpose, actually. It occurred to me
that this was a place where it made sense (albeit trivial) to want to
actually change the input, rather than just computing with it. And
since I had never used ref/out variables before, I decided to go for
it.

But you're not using the fact that you're passing it by reference.

In particular, using by-value variables, I would've had to specifically
*name* the control whose value I wanted to reset in the handler.

No you wouldn't. You can still pass the reference by value, and then
change the displayed DateTime.

I thought this "coupling" was unneccesary, and if I passed by reference,
I could say "change the value of whatever the input was, where ever it
came from".

But you're not changing it for another instance of DateTimePicker -
you're just changing the *contents* of the DateTimePicker.

It's perfectly possible, of course, that I am suffering from numerous
confusions - thanks for the page!

I suggest you try just removing the "ref" from your code (in both
declaration and call) and observe how the code still works - then read
the page carefully to understand why!

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Kevin Spencer]

Any date you can walk away from is a good one.

--
;-),

Kevin Spencer
Microsoft MVP
Ministry of Software Development
http://unclechutney.blogspot.com

I just flew in from Chicago with
a man with a wooden leg named Smith
who shot an elephant in my pajamas.
So I bit him.
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

sherifffruitfly <sh*************@gmail.comwrote:

http://www.pobox.com/~skeet/csharp/parameters.html

<snip--

Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[sherifffruitfly]

Jon wrote:

sherifffruitfly <sh*************@gmail.comwrote:

http://www.pobox.com/~skeet/csharp/parameters.html
>
(Note that even though DateTime is a struct, DateTimePicker is a
class.)

Thanks Jon. I was doing that on purpose, actually. It occurred to me
that this was a place where it made sense (albeit trivial) to want to
actually change the input, rather than just computing with it. And
since I had never used ref/out variables before, I decided to go for
it.

But you're not using the fact that you're passing it by reference.

I suggest you try just removing the "ref" from your code (in both
declaration and call)

Aw damn - you're right of course. Changing the object and changing the
value of a property of the object aren't the same thing. Sigh. And I
was so excited have found a "naturally occuring" pass-reference
sitution. :(

lol! Thanks for going slowly with me!

cdj