Develop Reference

Handling wpf drop of external programs

I'm trying to fiddle with an idea, and one big concept is dropping programs, bookmarks, etc. I have what I believe to be the gist of it but I'm not receiving any information
private void Border_Drop(object sender, DragEventArgs e)
{
FileInfo[] files = (FileInfo[])e.Data.GetData(DataFormats.FileDrop);
foreach (FileInfo file in files)
{
Writer.Text += file.FullName;
}
}
Though my textblock is never populated? I'd like to get all the properties of File such as FullName, Name, Extension, DirectoryName, etc.
Any pointers on where to go from here? I've been trying to read the MSDN of the event but nothing is coming up, and I've searched stackoverflow and nothing is working for my case scenario.

One possible reason is that you have attached the event handler to the wrong control. Try attaching the event handler to the Form, or if that does not work, the textblock.
I would also highly recommend doing some debugging. Place a breakpoint in the event handler to see if it is called, and if so, what happens in it.

WPF has two different routed event handling mechanisms: bubbling and tunneling. Bubbling is the "normal" way to do it, and tunneling is when you see all those PreviewThis and PreviewThat in the event name. It's possible, that another control has aready marked the event as handled, and so you don't see it in your event handler.
If you need documentation for WPF drag and drop, read this
If you need some really custom, really low level stuff on this subject, you can also read up on Object Linking and Embedding This is probably how drag-and-drop is implemented in Word so that you can drag images and Excel tables into Word documents and they will display natively. But to use this you will probably need to use some Win32 API calls which is a bit of a bummer.

C# Form Application: How to avoid deleting the unwanted events "manually" from InitializeComponent()?

This is a simple scenario:
I add an event to a control on the form by double clicking on its field (in Events part). But, then I decide that it was unnecessary and delete the automatically generated method. I'll run the program and it gives an error telling me that the event still exists in the InitializeComponent() and I must delete it from there.
So, is there anyway to avoid deleting the event "manually"? Is there anyway to fully delete it without leaving any trace (specially in InitializeComponent())?
Update: Also, another question arose:
When I delete the method from the code, the method name in the event field will disappear. So, if the InitializeComponent() is linked to these events, why isn't it updated with the empty event field?

You should use again the events grid and right click on the event you have inserted.
Select the Reset Menu option. This will remove the event handler assigned in the InitializeComponent and the code of the emtpy event in the code designer.
Note, that if you add code at the event, Visual Studio doesn't remove the new code.

The best way to do this is through the Properties grid in the Designer. You can click the Reset button or just delete the text and it will remove the event hook-up in the InitializeComponent() method. If your method is empty in your code behind, it will also delete it there:
It makes sense that you would have to manually delete the method body if it contains code in case it accidentally got Reset in the designer or if your method is referenced from some other part of your code. Visual Studio is gong to err on the side of caution.
If you delete the method body first, the reason it is not deleting the references to it probably in part has to do with cutting-and-pasting code. If you wanted to move the method to a different place in your code, the acting of cutting it would sever the references to it. After you pasted it, then you would wonder why your event was no longer be called. Again, error on the side of caution since it's not that difficult for the developer to track down extraneous code.

This pertains to C# 2017. So hopefully it would help others.
I'm new to C# (or at least back to code it) and ran with the same issue.
I commented out the event that I did by mistake. Then in the Error list, you will find an error there because that event is missing. Double click on it. It'll take you to the Designer code that "wires" the event. Once there, find the unwanted event and comment it out/delete it. Take care!

Look at the properties window when you select the Control. Click on the little flash and you'll see the Events listed, along with your event (Click or whatever), and your event will have the name of the assigned method behind it. Just delete that method.
That deletes the method, only if it's empty and otherwise unused though, which is quite reasonable. After all you might have put a lot of work into that event handler. (note: Just tried it again and apparently it doesn't always delete empty methods even though it did a few minutes ago. weird.)

In the designer you go to the events tab for the control in question, select the event that has the unwanted handler; and delete the name of the handler. Then save the form again.
This doesn't delete the method itself I think, (possibly unless it's empty or just been added).
Update
I dare say the reason for why it nearly always doesn't delete the method is because it could be used as a handler on another control's event. After all, in the UI you only asked to remove one event's handler; not every handler bound to that method. Then there's the question of whether the back-end code is dirty (i.e. unsaved) - checking whether the method is empty or not isn't reliable in that case. Yes, all of these could be worked around, but having to delete the method manually isn't exactly a hardship :) and at least this way VS doesn't end up deleting methods you actually want to keep.

Go back to the form and hit CTRL+Z.

C# : filesystemwatcher class

i have a question about the moving file event on filesystemwatcher class , i`d like to stop the moving of file or edit it when the moving file event arises for a certain file , is that possible to handle inside the moving event ?

No, there is no way to stop someone moving or renaming a file using the FileSystemWatcher class.
If you look, none of the event arguments passed by the events on the FileSystemWatcher class have a Cancel property. Also, the fact that the class is simply called a Watcher is a bit of a clue.
You might consider using Access Control Lists to make sure someone cannot delete a file (since a move is really just a copy/delete). Or perhaps you could try opening a FileStream on the file so that you have it locked.

You cannot directly "cancel" the operation by means of the event handler. You would have to provide a compensating operation to programatically "undo" any changes you want undone.

You only receive the events after the fact has happened. It's a mere notification, not an event you'd have to approve. This can also be guessed from the missing Cancel or Handled property in the FileSystemEventArgs (as opposed to, for example, the KeyEventArgs) class.
You can detect a move and try to move the file back, based on the OldFullPath property of the RenamedEventArgs you receive.
This might however be confusing to your users or to other software. And try not to end up in an infinite loop, where you move the file back and forth every time you receive the event.

WinForms control event handler gets removed when selecting another one and thus it becomes 'unreferenced'

Question about the WinForms designer and how to customize behavior. What I've seen multiple times is that when you select a different event handler for a button it will remove the old one (as in ,the code) when it becomes unused.
I want to avoid this behavior but can't find configuration for this. Anyone a hint? Thanks!
Update
Since multiple comments question the actions that trigger this in the first place, I'd like to point out that it has mostly hit me during refactoring of an existing code base.

There is no configuration for this. The designer does the Right Thing, it only removes event handlers that have no code. As soon as you put something in the method body then it preserves what you've written and generates a new method. This ensures that you don't lose code and ensures that you don't have dead methods littering your code.
Beware that adding more than one event handler for a control's event in the same class (form) makes very little sense. You should just merge the code of the handlers. This also ensures that you won't have any surprises, the order in which multiple subscribers for the same event runs is fairly unpredictable. The designer only supports a single event handler, simply because it doesn't have any way to track more than one.

This is just the way the Designer works - you can't change it.
What you can do to work around your problem is to add your event handlers in code, rather than in the designer:
public Form1()
{
InitializeComponent();
this.button1.Click += new EventHandler(button1_Click);
this.button1.Click +=new EventHandler(button1_Click2);
}
I must point out that I question the need for two separate event handlers.

Where to register for C# events?

I am currently transitioning from VB to C# and am having some issues with regards to registering my interest in an event.
When using VB it was simply a case of specifying that a method Handles and event, often this was generated by using the object events list. While I can easily use the Class.event += delegate in C# I am unsure where the best place is to place the code to do this.
Am I best placing it inside of the InitializeComponent() as per the generated code (say if you select the event in the from designer) or should I place it inside the constructor for better readability/maintenance. If inside the constructor, should it be before or after the call to InitializeComponent()?

When you are doing WinForm development (judging from InitializeComponent() function mentioned), usually you assign the handler using Visual Studio. You look up the properties of your control, click on the lightning icon to get the list of all events, find your event, and either double click on it (to create a new handler), or select existing handler from the list. Visual Studio will add the wiring of this in the generated code, so you don't have to worry about it.

I always create a private method called Init() and place it there, and then call that method from the constructor or the Form_Load event handler. It's semantically better, IMO, than doing it within the constructor proper. And you don't want to place it within InitializeComponent(), because next time you change something in your designer it's likely to delete any manually-added code there.

Sometimes Visual Studio's designer can mess up the code, so adding the event handlers within InitializeComponent can create a headache, it would be better to do it something like this
public Form1(){
InitializeComponent();
WireUpEvents();
}
public void WireUpEvents(){
this.fooEvent += new EventHandler(foo_handler);
.... etc ....
}
And make sure that you remove the event handlers in the Form's Dispose function also...
public void UnWireEvents(){
this.fooEvent -= new EventHandler(foo_handler);
.... etc ....
}
As you design the form, Visual Studio will change the code within the InitializeComponent() method located in form.design.cs, so it is imperative that you do not manually edit this code..

It depends, but most of the time, yes.
Use InitializeComponent when you want the event to be hooked for the entire duration of the Form (I'm assuming you're talking about Forms/UserControls/etc.). In other cases, you'll want finer grained control of when the Event is handled.
Keep in mind that you'll want to unhook all of these events (using the -= syntax) when you're Disposing the Form, or no longer want to handle the event. Keeping the event handler delegates attached is one of the most common managed memory leaks around.

Do not manually add code to the InitializeComponent() method. This method is code generated, so as soon as you change your form, any logic that you've added manually to this method will be wiped out.
I usually add a method to handle the Form's Load event and put my event registrations there.

If you have the InitializeComponent() method you're using the designer so you can bind events directly in the designer if you like. To do this, click the lightning bolt icon in the properties window and you'll see a list of all the events for the selected object. You can just type the name of the event in there and it'll create the code for you.
If you're not a fan of the designer, bind them after your InitializeComponent call and make sure you detach them when you're done (in Dispose()).

2 ways of doing this. You can either create you own method which you call in your Constructor which in turn creates the Event Handler, or you can just place them in your Constructor. Probably a good idea to remove the Event Handlers in your Finalizer/Destructor code.

I would place it after InitializeComponent, since you might be registering events against a child control/object, like a button, and you will want to be sure the object has been created already.
There will be cases where you wire up to events dynamically/conditionally in other places, such as in response to some other event.