how to pass a variable to a timer's handler?

[Jason Sobell \(iGadget\)]

Larry, perhaps I was wrong and you really are an idiot, or then again
perhaps you are just incredibly obstinate and simply refuse to acknowledge
an error.
I hope it's the latter, but whatever the reason, I have lost all desire and
inclination to respond to such a pile of weak arguments.
I'll keep monitoring this thread on the offchance you post the queue based
solution you recommended in your first response.

Cheers,
Jason

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:3dbe01cb@tnews.web.devx.com...
> "Jason Sobell (iGadget)" <iGadget_@hotmail.com> wrote
>
> > > I explained how your 'little change' modified the problem
>
> >
> > Show me where you explained this?
>
> It certainly wasn't back in the original discussion which must have been
> where you were looking. See the message posted Mon at 11:23am. The one
> containing my posted solution.
>
>
> > You claimed that the .Contains method
> > addressed this efficiently. I don't have to cut and paste your comments
to
> > this effect, but take the time to browse back through this thread.
>
> Trying to nit pick details, eh? You are way off base, I never said the
..Contains
> method was efficient, I said using a queue could be easily done.
>
> > As I said, take that requirement out and show me a solution using a
queue.
>
> OK, soon after you show a full solution using a hashtable.
>
> > Update the DB with the response time? What are you talking about?
>
> My slip, in the heat of the moment. Updated information has a time
element.
> In this case that element was not defined, it was the updated information
that
> needed to go to the DB. Sending multiple requests could 'very easily'
return
> different results, or return nothing at all. Without keeping track of the
response
> time you have no idea how current those results are. You have focused on
a
> minute aspect of the problem (debouncing) without taking the whole
> implementation into consideration. I saw that early on and told you that
table
> is not forward looking.
>
>
> > "user(from server) may click the client's info from treeview and it will
send
> > a request to client.. asking for the updated info.. then update the
central
> > database..
> > problem is we dun wan the user( from server) to send the request many
times,
> > when the user starts clicking.. right? so, i set a timer on the treeview
> > afterselect.."
> >
> > You seem to be altering the original requirements to justify every
change
> > you make and support all your misunderstandings.
>
> You're the who altered the problem with 'a little change'. Where does he
say
> he needed two different debounce times?
>
>
> > > > It's nice to see that you have used a HashTable in your solution
though
> > >
> > > I don't see any reference to a hashtable there....
> >
> > Unfortunately you are just reinforcing your ignorance of the workings of
> > .NET :/
> > Go to the framework directory...
> > Quote: "You got to learn to think outside the box... <g>"
>
> That wasn't my code, I used a collection. The fact that MS wraps a
collection
> around a hashtable and arraylist does not effect the code I wrote. That's
> called encapsulation, a black box is a black box. Since you didn't
recognize it
> for what it is, that must mean you are woefully ignorant of the OOP
paradigm!
>
>
> > Your suggestion for using a queue was valid but a poor choice, and since
> > being asked to support your argument you have painted yourself into a
corner
> > then managed to twist the whole thing around, showing that you have
> > suprisingly little experience of applying solutions to real-world
scenarios.
>
> It does little good to suggest a solution without making sure the
implementation
> is possible. You suggested you would use a keyed pair and I suggested
using
> a queue (collection) of objects. At that time both would work, and I
indicated
> as much, but then you challenged my suggestion. In the insuing
discussion,
> you changed the problem, and jumped on me for changing the requirements.
>
> I provided a working solution, that showed exactly where to send the
request,
> and where to update the DB, and would handle the debouncing issue. You
> provided code to handle a limited debouncing scenareo and called it a
> complete solution. Finally, instead of following up with a complete
solution,
> you say I twisted it all around an have little experience with
'real-world' scenarios.
> With what you suggested, I'd bet you've got a chronic case of not-my-job
> syndrom.
>
> Now wasn't that entertaining....
> LFS

[Larry Serflaten]

"Jason Sobell (iGadget)" <iGadget_@hotmail.com> wrote
> Larry, perhaps I was wrong and you really are an idiot, or then again
> perhaps you are just incredibly obstinate and simply refuse to acknowledge
> an error.

Likewise. I see you're familiar with the terms....


> I hope it's the latter, but whatever the reason, I have lost all desire and
> inclination to respond to such a pile of weak arguments.

Translation: My shortsighted partial suggestion would be too difficult to
make into anything more robust than whats already there.


> I'll keep monitoring this thread on the offchance you post the queue based
> solution you recommended in your first response.

As I said, I will get to it after you provide a full solution to original problem.
At first glance it appears I will be seeing a net reduction in lines of code. I
can't say the same for your flash in the pan....

LFS

[Jason Sobell \(iGadget\)]

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:3dbe2f13$1@tnews.web.devx.com...
> > I'll keep monitoring this thread on the offchance you post the queue
based
> > solution you recommended in your first response.
>
> As I said, I will get to it after you provide a full solution to original
problem.
> At first glance it appears I will be seeing a net reduction in lines of
code. I
> can't say the same for your flash in the pan....

Humour me here, and tell me what do you think the original problem was. I
seem to have completely misunderstood.

"problem is we dun wan the user( from server) to send the request many
times,
when the user starts clicking.. right?"

My understanding:
The user needs a method of detecting whether or not a request has been sent
to a certain machine within the last 'n' seconds, and prevent sending any
additional requests if this is the case.

What is your understanding of that statement?

Cheers,
Jason

[Jason Sobell \(iGadget\)]

Larry, your silence speaks louder than any further excuses you might post
Speak now, or we concede the error of your ways and we can class this thread
as closed.

Cheers,
Jason

"Jason Sobell (iGadget)" <iGadget_@hotmail.com> wrote in message
news:3dbe589d@tnews.web.devx.com...
> "Larry Serflaten" <serflaten@usinternet.com> wrote in message
> news:3dbe2f13$1@tnews.web.devx.com...
> > > I'll keep monitoring this thread on the offchance you post the queue
> based
> > > solution you recommended in your first response.
> >
> > As I said, I will get to it after you provide a full solution to
original
> problem.
> > At first glance it appears I will be seeing a net reduction in lines of
> code. I
> > can't say the same for your flash in the pan....
>
> Humour me here, and tell me what do you think the original problem was. I
> seem to have completely misunderstood.
>
> "problem is we dun wan the user( from server) to send the request many
> times,
> when the user starts clicking.. right?"
>
> My understanding:
> The user needs a method of detecting whether or not a request has been
sent
> to a certain machine within the last 'n' seconds, and prevent sending any
> additional requests if this is the case.
>
> What is your understanding of that statement?
>
> Cheers,
> Jason
>
>

[Larry Serflaten]

"Jason Sobell (iGadget)" <iGadget_@hotmail.com> wrote
> Larry, your silence speaks louder than any further excuses you might post
> Speak now, or we concede the error of your ways and we can class this thread
> as closed.

You continually act as if you have not read a single word of my posts. You ask
the same questions time and time again, reworded, rephrased, as if I did not already
provide an answer. If you were a student, with a desire to learn, I would probably
overlook most of that, and early on, I did, by habit. But you are supposedly
more informed than a student, so I will not be party to pettifogging tactics.


> > > > I'll keep monitoring this thread on the offchance you post the queue based
> > > > solution you recommended in your first response.
> > >
> > > As I said, I will get to it after you provide a full solution to original problem.


I have already described what the differences were, and why they are important.
When I see your revised edition, I'll have a look, and may respond....

LFS

[Phil Weber]

OK, boys, this is a technical discussion group. Continued bickering helps no
one. If you must persist, please take it to another group (vb.dotnet.discussion
would be fine). Thank you!
--
Phil Weber

[Rune Bivrin]

Pardon my jumping in, but the absence of input from my part is mainly
due to the lack of a problem description everyone - in particular
Brandon - agrees on. Lacking that, every solution is most likely good
enough for the problem it's desigend to solve.

However, I must agree that given the initial problem as described by
Brandon (once the timer was removed), the choice of a queue is somewhat
surprising. I'd stuff a date containing the request send time in a
collection of some sort, with client ID as the key, and then check that
collection on every click for time since last request sent.

--
Rune Bivrin
- OOP since 1989
- SQL Server since 1990
- VB since 1991


"Jason Sobell \(iGadget\)" <iGadget_@hotmail.com> wrote in
news:3dbfb05e$1@tnews.web.devx.com:

> "Phil Weber" <pweber@nospam.fawcette.com> wrote in message
> news:3dbf997a$1@tnews.web.devx.com...
>> OK, boys, this is a technical discussion group. Continued bickering
>> helps
> no
>> one. If you must persist, please take it to another group
> (vb.dotnet.discussion
>> would be fine). Thank you!
>
> Well, this started as a technical discussion, but the complete lack of
> input by anyone else has resulted in this ridiculous situation. It's a
> shame that the only other response is yours. Perhaps if you had
> contributed your opinions earlier in the thread we might have found a
> third more suitable solution to the problem?
> I'm disappointed that nobody else seems to have any opinion on the
> matter, but I now realise that any kind of further 'discussion' is
> futile so I won't be posting anything else on this thread.
>
> Cheers,
> Jason
>
>
>

[Jason Sobell \(iGadget\)]

"Phil Weber" <pweber@nospam.fawcette.com> wrote in message
news:3dbf997a$1@tnews.web.devx.com...
> OK, boys, this is a technical discussion group. Continued bickering helps
no
> one. If you must persist, please take it to another group
(vb.dotnet.discussion
> would be fine). Thank you!

Well, this started as a technical discussion, but the complete lack of input
by anyone else has resulted in this ridiculous situation. It's a shame that
the only other response is yours. Perhaps if you had contributed your
opinions earlier in the thread we might have found a third more suitable
solution to the problem?
I'm disappointed that nobody else seems to have any opinion on the matter,
but I now realise that any kind of further 'discussion' is futile so I won't
be posting anything else on this thread.

Cheers,
Jason