|
Call the mouse Click event in the Mouse hover event
|
|
|
|
|
Hi,
AFAIK you can move the mouse pointer with the Cursor.Position property.
and you can simulate a button click with the Button.PerformClick() method (there is
no need to move the mouse for that to work!)
|
|
|
|
|
Unfortunately it is not a button I want to click (I know, I used it in the question :P, I need to paint automatically in a panel), but thanks anyways. I decided to use a variable which is activated when the bot is activated, and use the mouse_move event instead.
modified on Tuesday, May 6, 2008 4:58 PM
|
|
|
|
|
Hi All,
I have a program that can be started as windows service or as an
windows app.
I need to avoid starting this program as an application if it is
already started as a win service.
In code when program starts as a win service I create named mutex.
Then if user tries to start program as a win application I am checking
if Mutex with the same name exists already and exit program if Mutex
found.
My problem is that Mutex that was created when program started as win
service cannot be found when program starting as a win application.
If I try to run program as a win application twice ( program is not started as a win service at this time) during second attempt Mutex is found.
I would appreciate if anyone can point me how to fix this.
Thanks,
Roman
|
|
|
|
|
Never mind,
I fixed it by using @"Global\MyMutexName" as a mutex name
|
|
|
|
|
Are you running on Vista? Vista runs services on a different session from applications, so that might be your problem. Try prefixing Global\ to your mutex name and see if it works.
|
|
|
|
|
Thanks for response,
I am running Windows XP and I have .NET 3.0 installed. On the box where .NET 3.0 is not installed I can find mutex created in service without using Global\ in mutex name. I think .NET 3.0 is the cause for such behaviour.
Roman
|
|
|
|
|
I've seen a lot of code that looks something like the following:
using (using (FileStream fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None))
I realize that this ensures that everything will be properly closed and disposed without you having to do anything, but doesn't the same thing happen when the object goes out of scope? Further, what about exception handling? Is that automatically handled as well?
Is it wrong to not want to sue this construct in favor of more obvious code?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John
using is a convenience that hides the following pattern:
FileStream fs = null;
try
{
fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None);
}
finally
{
((IDisposable)fs).Dispose();
}Basically, this guarantees that the Dispose method is called regardless of whether an exception happens or not, thus freeing up unmanaged resources in this case. If a class has a Dispose method, then it should always be called because (presumably) the developers have identified that particular items have to be freed up probably because they are expensive to maintain. The added bonus here is that most implementations of Dispose call GC.SuppressFinalize(...); so the finalizer (if any) is suppressed.
|
|
|
|
|
Pete O'Hanlon wrote: ((IDisposable)fs).Dispose();
Just wondering why this cast ? fs.Dispose() will do it, Right ?
|
|
|
|
|
The object will be freed, but any unmanaged resources will linger unless freed up. Implementing the IDisposable interface is the recommended way to do that. And as someone mentioned using is just a shorthand way to call it safely.
Eventually the garbage collector will collect the object; however, that doesn't necessarily free resources. The finalizer will be called unless suppressed, but that will only call Dispose if you specifically do so in your finalizer code.
N a v a n e e t h wrote: Just wondering why this cast ? fs.Dispose() will do it, Right ?
The object may not directly implement the interface, but may have explictly implemented it. In that case its necessary to cast the object to IDisposable.
|
|
|
|
|
tgrt wrote: The object may not directly implement the interface
Did you mean "implicitly"? Both implicit and explicit implimentations are direct, surely?
|
|
|
|
|
Yeah. I just don't like that word. I guess direct wasn't the best substitute.
|
|
|
|
|
>>Eventually the garbage collector will collect the object; however, that doesn't necessarily free resources. The finalizer will be called unless suppressed, but that will only call Dispose if you specifically do so in your finalizer code.<<
The using command, especially when applied to IO resources, is more complex than just calling Dispose.
For example take this segment of code:
using ( FileStream list = Text.OpenWrite( path ) )
{
foreach ( UniqueObject item in myArrayOfObject )
{
list.Write( UniqueObject.Message, UniqueObject.GetAverage() );
}
}
When you exit the using block, three things will happen. The buffer will be flushed, the file will be closed, and the object will be disposed of. Likewise (and more importantly) if UniqueObject.GetAverage() blew a divide by zero exception your code would leave this execution block. When that happens....using will flush the buffer, close the file, dispose of the object.
This process first and formost protects long-running application from creating memory leaks leaving these streams and rare resources around. Secondly it ensures that any unmanaged resources (like file handles) are released. Finally it ensures that even an exception will not cause your file to get corrupted by early interuptus.
|
|
|
|
|
LongRange.Shooter wrote: The using command, especially when applied to IO resources, is more complex than just calling Dispose.
Nope. It's not. It just calls Dispose. Dispose is responsible for calling Dispose(true), which performs the following code:
protected override void Dispose(bool disposing)
{
try
{
if (((this._handle != null) && !this._handle.IsClosed) && (this._writePos > 0))
{
this.FlushWrite(!disposing);
}
}
finally
{
if ((this._handle != null) && !this._handle.IsClosed)
{
this._handle.Dispose();
}
this._canRead = false;
this._canWrite = false;
this._canSeek = false;
base.Dispose(disposing);
}
}So, the using block is still about predictably calling Dispose. Don't confuse the effect with the implementation. BTW - there are conditions where the Dispose is not called - in an out of memory or stack overflow, the application bombs straight out (and doesn't hit the Dispose).
modified on Wednesday, May 7, 2008 3:39 PM
|
|
|
|
|
Nitpicking here, but you forgot if (fs != null) . The finally block looks like
if (fs != null)
((IDisposable)fs).Dispose();
|
|
|
|
|
Spot on. Sorry and all that. 
|
|
|
|
|
Pete O'Hanlon wrote: because (presumably) the developers have identified that particular items have to be freed up probably because they are expensive to maintain.
Great. And isn't this very similar to responsibility for memory allocation and freeing that makes a Garbage Collection environment so desirable?  I mean you'd think a VB developer that can actually understand the Dispose Pattern could handle new and delete. I'm just saying... 
led mike
|
|
|
|
|
I don't call dispose on streams, but I do call close(). Isn't that the same thing?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: I don't call dispose on streams, but I do call close(). Isn't that the same thing?
Yes, as long as you guarantee that Close() is called. As I stated earlier, the using statement wraps a try/finally block, so you need to ensure that Close is called in the finally portion.
|
|
|
|
|
|
John Simmons / outlaw programmer wrote: using (using (FileStream fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None))
I think this statement is wrong. You can use nested using statements in this way
using(DisposableObject1)
using(DisposableObject2)
{
}
John Simmons / outlaw programmer wrote: but doesn't the same thing happen when the object goes out of scope?
Do you mean it will be disposed when the scope ends ? GC will handle it, but there would be a delay in disposal. This will produce same IL which try/finally is producing. So it's just a syntactic shortcut to call Dispose() method which ensures immediate disposal.
|
|
|
|
|
John Simmons / outlaw programmer wrote: but doesn't the same thing happen when the object goes out of scope?
Yes but garbage collection is non-deterministic and using offers deterministic resource clean up. I'm just the messenger, don't shoot me!
led mike
|
|
|
|
|
GC and dispose are also doing different stuff.
GC frees the memory allocated by the managed object.
Dispose is supposed to release native resources allocated by an object.
So even if you call dispose, the managed object is still present untill it gets eaten by the GC.
|
|
|
|
|
John Simmons / outlaw programmer wrote: I realize that this ensures that everything will be properly closed and disposed without you having to do anything, but doesn't the same thing happen when the object goes out of scope?
No, it doesn't. The memory management doesn't use reference counting, which means that nothing happens because of an object going out of scope.
Because there is no possibility to add any code that will run when the object goes out of scope, the IDisposable interface was created, so that the lifetime of an object could be controlled from the code.
Ordinary objects that doesn't have a specific need for any cleanup, doesn't have a Dispose method. They will just be removed when the garbage collector notices that the can be.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
