Want form to show changing data. But it could be closed, or closing, during update.

[Zytan]

(Note that I use the word "event" in two different ways above...in the

first two cases, I'm talking about a waitable event, in the third case I'm
talking about a .NET event using the C# "event" keyword. Two *very*
different concepts).

My lack of knowledge and comfort with events limits me from deciding
which of these methods is the best. They all seem rather
complicated. But, they all seem to be 'proper' solutions, where as
what I have now is sort of a hack.

I also am not sure that you couldn't just accomplish all of the above
using just the form and the network i/o code, but it seems to me that
having the intermediate class might make the separation of duties clearer
and easier to maintain.

Yes, and that's what I was hoping to avoid, but I can see that it's
quite complicated just to have a display of data that changes
constantly. Basically, having an intermediate class is the solution,
and once it's done, it could be reused easily. I don't currently have
a large need for this, though, and my simple hack is fine for now. I
wish I had the time to do this properly, but I don't.

Thanks for all of your help, it's been great.

Zytan

 

[Peter Duniho]

My lack of knowledge and comfort with events limits me from deciding
which of these methods is the best. They all seem rather
complicated. But, they all seem to be 'proper' solutions, where as
what I have now is sort of a hack.

For what it's worth, you might as well learn about events. You already
are a client of events in your code if you're using .NET anyway, and while
I might be misusing them, the only thing I ran into that was a little
counter-intuitive was the need to copy the event used for subscribing to a
local variable before actually executing it.

Basically, an event looks a lot like a delegate in code; the main
difference is that when you "execute" an event, what really happens is
that all the delegates that have been subscribed to the event get executed
with the same parameter list (provided in the line that "executes" the
event).

In fact, in situations where you know you will only ever have a single
delegate subscribed, I suppose you could just use a delegate variable
instead of an event. The way the work is so similar, it'd be hard to
notice the difference.

You may not want to use them here, but there's really no reason to be
scared of learning them. They are a pretty straight-forward concept.

Note: in the above I am talking about the .NET "event", not the wait
handle type "event".

Pete

 

[Zytan]

Basically, an event looks a lot like a delegate in code; the main

difference is that when you "execute" an event, what really happens is
that all the delegates that have been subscribed to the event get executed
with the same parameter list (provided in the line that "executes" the
event).

So, it's just as if I had an array of function pointers, and I called
each one of them. And they are subscribed to the event by adding
themselves in this array.

In fact, in situations where you know you will only ever have a single
delegate subscribed, I suppose you could just use a delegate variable
instead of an event. The way the work is so similar, it'd be hard to
notice the difference.
Yes.

You may not want to use them here, but there's really no reason to be
scared of learning them. They are a pretty straight-forward concept.

Yes, it's a very simple concept.

Zytan