|
Can you convince us that this isn't going to be a "keylogger", something that is a severe security risk??
|
|
|
|
|
How do I convince you, that I'm not going to violate security?
only thing I can say, that if u believe then plz help me...
Actually I’m working on this from past few days, and getting a problem when trying to create a windows service.
Service.cs is not allowing to add namespace System.Windows.Forms, so that I can get the key codes, so if anyone help me regarding this it will be very helpful.
|
|
|
|
|
Somnath Sen wrote: Service.cs is not allowing to add namespace System.Windows.Forms, so that I can get the key codes, so if anyone help me regarding this it will be very helpful.
That is for a good reason. Services aren't supposed to have a UI, as they aren't supposed to have any user interaction. They are used for running backround operations without user interaction. Good luck convincing anyone you aren't writing a keylogger.
"If an Indian asked a programming question in the forest, would it still be urgent?" - John Simmons / outlaw programmer
I get all the news I need from the weather report - Paul Simon (from "The Only Living Boy in New York")
|
|
|
|
|
Somnath Sen wrote: How do I convince you, that I'm not going to violate security?
You can't. It's as simple as that. We're not simply going to take your word for it.
|
|
|
|
|
Somnath Sen wrote: How do I convince you, that I'm not going to violate security?
You can't. It was a facetious question.
The System.Windows.Forms namespace will do you no good. It won't capture keystrokes system-wide. For that, you need to use the Win32 API and setup a certain callback. I refuse to say exactly what you have to do simply because there is no legitimate, nor legal, reason to write a "keylogger".
|
|
|
|
|
Consider the following code...
<br />
<br />
string text;<br />
foreach ( something )<br />
{<br />
if ( something )<br />
{<br />
text = "closing";<br />
someForm.FormClosing += delegate( object sender, FormClosingEventArgs e )<br />
{<br />
MessageBox.Show( text );<br />
};<br />
}<br />
<br />
if ( something_else )<br />
{<br />
text = "closed";<br />
someForm.FormClosed += delegate( object sender, FormClosedEventArgs e )<br />
{<br />
MessageBox.Show( text );<br />
};<br />
}<br />
}<br />
The foreach will have a something, and then a something_else, in this order. So, what will happen here, is that both events will trigger a MessageBox displaying "closed" text. To fix this, I passed the string text inside the foreach, and the issue isn't an issue anymore.
Now... can anyone explain me why does this happen? The delegate uses the reference instead of the value?
Gonçalo A.
|
|
|
|
|
Your question doesn't make any sense because you used terms that don't mean anything in the context that you used them in. You didn't fire an events, nor did you handle any. You didn't "pass in" a string called "text" inside the foreach.
On top of that, you didn't supply a complete code sample. In what method does this code show up?? What does the complete foreach look like?? Don't replace expressions with something and something_else. Your question is directly related to what those expressions really are.
|
|
|
|
|
Actually, no.. it has nothing to do with the something or something_else... that's why I didn't post it.
I'll try to simplify the code...
<br />
string text;<br />
<br />
if ( 1 )<br />
{<br />
<br />
text = "closing";<br />
someForm.FormClosing += delegate( object sender, FormClosingEventArgs e )<br />
{ MessageBox.Show( text ); };<br />
<br />
}<br />
<br />
if ( 1 )<br />
{<br />
<br />
text = "closed";<br />
someForm.FormClosed += delegate( object sender, FormClosedEventArgs e )<br />
{ MessageBox.Show( text ); };<br />
<br />
}<br />
Hope this clears out.
Gonçalo A.
|
|
|
|
|
Kensho wrote: Actually, no.. it has nothing to do with the something or something_else... that's why I didn't post it.
Kensho wrote: Hope this clears out.
No, it doesn't. What you described cannot happen with the "code" snippets you posted. Good luck...
|
|
|
|
|
Cannot... or won't?? You tried it?
Oh, there's just one detail on the code... replace the '1's with 'true'. Forgot that small detail in c#.
Just Create a form, and on the constructor, after the initializations, add these lines:
<br />
string text;<br />
<br />
if ( true )<br />
{<br />
text = "closed";<br />
FormClosed += delegate( object sender, FormClosedEventArgs e )<br />
{ MessageBox.Show( text ); };<br />
}<br />
<br />
if ( true )<br />
{<br />
text = "closing";<br />
FormClosing += delegate( object sender, FormClosingEventArgs e )<br />
{ MessageBox.Show( text ); };<br />
}<br />
And tell me if the output isn't "closing", "closing".
Gonçalo A.
|
|
|
|
|
Once again, the issue, as you described it, cannot occur with the code you posted. There is some tiny, yet important, little detail that's missing, (which you are ommiting because you think it's not important) that is probably causing this. If both if statements are using the same static value (NOT return values from two calls to the same function with the (supposedly) same data), then what you describe is not possible.
|
|
|
|
|
Cannot, or it doesn't happen? Or... if it could not happen, then why, instead of just... cannot happen.
Try it. Just as I described on my previous post. Create a new project, with a form, and type that out...
Even I did this, to prove myself I wasn't fooling anyone; so I am not freaking ommiting anything... sheesh...
This happens because when you add code like that, in runtime, the compiler will hold to the references and not to the values; the result is that both will grab the last value of the reference. That's why it won't happen if you switch the text variable to inside the if, or if you added static text like MessageBox( "closed" );.
Advice... do try it first, before saying it CANNOT happen. I won't hold a grudge on you if you try, I promise...
Cheers
Gonçalo A.
|
|
|
|
|
I ignored your last code post because it's not the same as your original post.
if (true)
...
if (true)
...
is NOT the same as:
if (something)
...
if (something_else)
...
Your last code post is identical in output to:
string text;
if (true)
{
text = "closed";
FormClosed += delegate( object sender, FormClosedEventArgs e )
{ MessageBox.Show( text ); };
text = "closing";
FormClosing += delegate( object sender, FormClosingEventArgs e )
{ MessageBox.Show( text ); };
}
The problem was never in the compiler, but in your logic.
|
|
|
|
|
You don't even need to put the if there...
Now... all this not to answer my question?? Come one... you can do better than that, can't you? If I said that it wasn't relevant, it's because it wasn't... Now... you can remove the if... are you gonna answer my question or are you just gonna pretend you're so very awesome?
Cheers
Gonçalo A.
|
|
|
|
|
Kensho wrote: Come one... you can do better than that, can't you? If I said that it wasn't relevant, it's because it wasn't
That's what YOU think. It WAS relevant. The key piece of information was, and still is, missing. I already explained to why that's the case, but you keep insisting that it's not. It's not me that has the problem, it's you. The first rule of asking a question is to listen.
Kensho wrote: Now... you can remove the if... are you gonna answer my question or are you just gonna pretend you're so very awesome?
I already answered this in my previous post. Sure, you can remove the if. Your code would still be this:
string text;
text = "closed";
FormClosed += delegate( object sender, FormClosedEventArgs e )
{ MessageBox.Show( text ); };
text = "closing";
FormClosing += delegate( object sender, FormClosingEventArgs e )
{ MessageBox.Show( text ); };
Perhaps you're misunderstanding what the two delegate statements are doing??
|
|
|
|
|
Kensho wrote: Come one... you can do better than that, can't you? If I said that it wasn't relevant, it's because it wasn't
That's what YOU think. It WAS relevant. The key piece of information was, and still is, missing. I already explained to why that's the case, but you keep insisting that it's not. It's not me that has the problem, it's you. The first rule of asking a question is to listen.
Kensho wrote: Now... you can remove the if... are you gonna answer my question or are you just gonna pretend you're so very awesome?
I already answered this in my previous post. Sure, you can remove the if. Your code would still be this:
string text;
text = "closed";
FormClosed += delegate( object sender, FormClosedEventArgs e )
{ MessageBox.Show( text ); };
text = "closing";
FormClosing += delegate( object sender, FormClosingEventArgs e )
{ MessageBox.Show( text ); };
Perhaps you're misunderstanding what the two delegate statements are doing??
|
|
|
|
|
If the code does the same, it WAS IRRELEVANT; if it was relevant, the code would do something different.
I'll just state the output of that code...
When you close the form, two message boxes will appear...
One will say "closing", and the other one will say "closing".
I said this right from the start.
Gonçalo A.
|
|
|
|
|
if (true){
text = "closed";
FormClosed += delegate( object sender, FormClosedEventArgs e )
{ MessageBox.Show( text ); };
text = "closing";
FormClosing += delegate( object sender, FormClosingEventArgs e )
{ MessageBox.Show( text ); };
}
So you mean to tell me that you thought text in each delegate would get a copy of the current contents of the text variable when the delegates were created??
You'll have to excuse me as I (wrongly) assumed you knew how variables worked. This was such a basic concept you were missing that I didn't even consider it a possibility that that's where you were misunderstanding the code. To me, it was obvious this would be the behavior. I originally thought that you were wondering why both sections of code were being run because both if statements were being evaluated to true.
|
|
|
|
|
bwahahahahaha I really had to laugh on this one...
And you're a Microsoft MVP??? Well... you're from VB, so... I guess I have to understand.
First... it's not a variable matter. It's a closures matter. And I said from the start what would happen; you were the one saying otherwise... so... don't try to cover up your stupidity now...
And... weren't you supposed to be here to help? Get over your frustration, it's unhealthy for this forum users.
Cheers
Gonçalo A.
|
|
|
|
|
|
In lack of a wiser answer... I don't mind...
Cheers
Gonçalo A.
|
|
|
|
|
Why not just send the strings directly, without assigning to a variable?
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
Skippums wrote: Why not just send the strings directly, without assigning to a variable?
ahahahahahah 
that's right, that would solve it. 
But that example is just an illustration of my problem. The actual code gets the contents from somewhere else dynamically, and it doesn't display a message box, it does something else... this was just to simplify. I actually solved this by moving the value holder inside the context, and this way, a new reference is always created.
Gonçalo A.
|
|
|
|
|
Kensho wrote: The actual code gets the contents from somewhere else dynamically...this was just to simplify
Exactly... that is why Dave asked you for more specific code. Clearly, you would have thought of this if it solved your problem; however, in your example this is a valid solution. Try to be slightly more specific in your problem statement so we can give "real" feedback instead of having to guess what the problem is. Glad you got it working,
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
Ok... the thing is... I had solved it since I posted the first message here.. I said it even... I only spoke about the positioning of the variable and the association to runtime delegate.
This is que only thing that I questioned:
Kensho wrote: Now... can anyone explain me why does this happen? The delegate uses the reference instead of the value?
delegate... value... I don't understand why the big fuss over a simple question.
But nevermind... I already got my answer... maybe someone can pick this up and find it useful, as a simple piece of information, as it is.
Cheers
Gonçalo A.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
