I decided to turn on the strict option on one of my applications. And for the life of me I couldn't figure out how to make a small bit of code compile. In a module I had this bit of code
Sub Main()
AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf CurrentDomain_UnhandledException
End Sub
Private Sub CurrentDomain_UnhandledException(sender As Object, e As UnhandledExceptionEventArgs)
e.ExitApplication = False
End Sub
after looking around and seeing another post about putting it in the ApplicationEvents I got it to work by handling said event. So out curiosity I decided to move the AddHandler and into the same class and then it became clear that its the same class name but different namespaces:
Partial Friend Class MyApplication
Private Sub MyApplication_UnhandledException(sender As Object, e As UnhandledExceptionEventArgs) Handles Me.UnhandledException
e.ExitApplication = False
AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf CurrentDomain_UnhandledException
End Sub
Private Sub CurrentDomain_UnhandledException(sender As Object, e As System.UnhandledExceptionEventArgs)
e.ExitApplication = False
End Sub
End Class
Here is a link to both:
Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs
System.UnhandledExceptionEventArgs
So my question is, which one should I use? I'm wanting to prevent the app from shutting down... but both options seem like what I want.
The System.UnhandledException doesn't have an ExitApplication member (see the docs you linked), so cannot be used to stop the application exiting - once this is called the application will always terminate. Generally the Microsoft.VisualBasic namespace are helpers for VB that more-or-less duplicate functionality available elsewhere. The closest equivalent to the VisualBasic handler that you mention is instead the Application.ThreadException one. This and the AppDomain.CurrentDomain.UnhandledException are both described quite well in the MS docs.
To prevent the app from shutting either the VisualBasic one or the ThreadException one can be used. I've used the Microsoft.VisualBasic one in the past to achieve something similar to what you are doing.
Related
I'm new to Visual Basic and overall kind of new to coding in general.
Currently I work on a program which uses a filewatcher. But If I try this:
Public Class Form1
Private WithEvents fsw As IO.FileSystemWatcher
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
fsw = New IO.FileSystemWatcher("PATH")
fsw.EnableRaisingEvents = True
' fsw.Filter = "*.settings"
End Sub
Private Sub GetSettingsFromFile()
Some Code
More Code
CheckBox1.Checked = True
End Sub
Private Sub fsw_Changed(sender As Object, e As FileSystemEventArgs) Handles fsw.Changed
fsw.EnableRaisingEvents = False 'this is set because the file is changed many times in rapid succesion so I need to stop the Filewatcher from going of 200x (anyone has a better idea to do this?)
Threading.Thread.Sleep(100)
GetSettingsFromFile()
fsw.EnableRaisingEvents = True 'enabling it again
End Sub
End Class
But when I do this (trying to change anyhting in the form) I get this error:
System.InvalidOperationException (WinForms.IllegalCrossThreadCall)
It wont stop the program from working, but I want to understand what is wrong here and why the debugger is throwing this at me
regards
The event is being raised on a secondary thread. Any changes to the UI must be made on the UI thread. You need to marshal a method call to the UI thread and update the UI there. Lots of information around on how to do that. Here's an example:
Private Sub UpdateCheckBox1(checked As Boolean)
If CheckBox1.InvokeRequired Then
'We are on a secondary thread so marshal a method call to the UI thread.
CheckBox1.Invoke(New Action(Of Boolean)(AddressOf UpdateCheckBox1), checked)
Else
'We are on the UI thread so update the control.
CheckBox1.Checked = checked
End If
End Sub
Now you simply call that method wherever you are and whatever thread you're on. If you're already on the UI thread then the control will just be updated. If you're on a secondary thread then the method will invoke itself a second time, this time on the UI thread, and the control will be updated in that second invocation.
I want to check out if several folders are receieving new files and then handle that. This works fine, I have declared the FileSystemWatcher and set the EventHandler.
Now, everything works fine and if I create a new file there, it notices it.
Then, I noticed that when I paste a file, it does not notice it. I have already searched on Google and I read that it is not possible with the built-in FileSystemWatcher so far.
So I thought about API to manage this, but I have actually no idea how to deal with that or where to start. This program is one for a job, so I really need that.
I appreciate any help, links or something else to deal with that.
Thanks! if something is not clear, avoid a Downvote and ask me ;)
The following works completed as expected (.net v4.5). A paste into the directory fires the Change event.
Public Class Form1
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
Dim fw As New FileSystemWatcher
fw.Path = "c:\Temp"
fw.Filter = "*.*"
fw.IncludeSubdirectories = False
AddHandler fw.Created, New FileSystemEventHandler(AddressOf FileWatcherFileChange)
AddHandler fw.Deleted, New FileSystemEventHandler(AddressOf FileWatcherFileDeleted)
AddHandler fw.Renamed, New RenamedEventHandler(AddressOf FileWatcherFileRenamed)
AddHandler fw.Error, New ErrorEventHandler(AddressOf FileWatcherError)
fw.EnableRaisingEvents = True
End Sub
Private Sub FileWatcherFileChange(ByVal source As Object, ByVal e As FileSystemEventArgs)
MsgBox("Change")
End Sub
Private Sub FileWatcherFileDeleted(ByVal source As Object, ByVal e As FileSystemEventArgs)
MsgBox("Deleted")
End Sub
Private Sub FileWatcherFileRenamed(ByVal source As Object, ByVal e As FileSystemEventArgs)
MsgBox("Renamed")
End Sub
Private Sub FileWatcherError(ByVal source As Object, ByVal e As System.IO.ErrorEventArgs)
MsgBox("Error")
End Sub
End Class
There were so many comments, I want to ensure you read this so I post as an answer. Please read this answer from me in another thread in full, including what is written on CodeProject. If what you are delivering is important work code you should really take the time to read it all.
This FileSystemWatcher class features many surprises. It is a leaky abstraction - it doesn't work in any way like it should. It might work for a while, but it always fails when conditions change.
If I were you I would ditch the FileSystemWatcher class entirely and work with time and date based scans for new files. There may be other classes and pre-made components that can help you with this.
UPDATE: New information: https://stackoverflow.com/a/23704476/129130
To start with I have a fairly unique situation in that I am dealing with large amounts of data - multiple series of about 500,000 points each. The typical plot time is about 1s which is perfectly adequate.
The chart is created 'WithEvents' in code and the plot time doesn't change.
However, when I add the sub with the handler for the click event ..
Private Sub Chart_Main_Click(ByVal sender As Object, _
ByVal e As MouseEventArgs) Handles Chart_Main.Click
Dim y As Integer = Chart_Main.ChartAreas(0).AxisX.PixelPositionToValue(e.X)
'MsgBox(y)
End Sub
the plot time blows out to 3min. Even having no code in the sub, the result is the same. There is no reference to the click event in any of the code so I am at a loss as to why this is occurring. I suspect it has something to do with the number of points being added but not knowing the cause is frustrating.
Is anyone able to explain what is going on?
Ok, i don't know if the explanation in the comments was sufficient, so here some example code...
Also i wanted to try this myself!
Essencially, what you do is take control on when you want Windows to check the events.
For that, i suggested two wrappers on AddHandler and RemoveHandler that can safely be called from worker threads.
So, what you have to do, is:
Initialize the Handler in the constructor
Call RemoveClickHandler on your control, each time you want it to be left alone by the EventHandler
But don't forget to reinitialize the handler afterwards via AddClickHandler
Also, your handler method should not have the 'Handles' keyword anymore...
Public Class MainForm
Public Sub New()
' This call is required by the designer.
InitializeComponent()
m_pPictureClickHandler = New MouseEventHandler(AddressOf hndPictureClick)
AddClickHandler(pbxFirst, m_pPictureClickHandler)
End Sub
' Have a persistent local instance of the delegate (for convinience)
Private m_pPictureClickHandler As MouseEventHandler
Public Sub AddClickHandler(obj As Control, target As [Delegate])
If Me.InvokeRequired Then
Me.Invoke(New Action(Of Control, [Delegate])(AddressOf AddClickHandler), obj, target)
Else
AddHandler obj.MouseClick, target
End If
End Sub
Public Sub RemoveClickHandler(obj As Control, target As [Delegate])
If Me.InvokeRequired Then
Me.Invoke(New Action(Of Control, [Delegate])(AddressOf RemoveClickHandler), obj, target)
Else
RemoveHandler obj.MouseClick, target
End If
End Sub
' Here your Plot is done
Public Sub LockedPlot()
RemoveClickHandler(pbxFirst, m_pPictureClickHandler)
' do something on your handler free control ...
AddClickHandler(pbxFirst, m_pPictureClickHandler)
End Sub
' This is your handler (note without a 'Handles' keyword)
Private Sub hndPictureClick(sender As Object, e As MouseEventArgs)
' do something with the click
MessageBox.Show(String.Format("Yeah! You clicked at: {0}x{1}", e.X.ToString(), e.Y.ToString()))
End Sub
End Class
I suppose an even better design would be to create a child class of your chart that has an LPC style method called, say 'SafePlot', with folowing features:
It accepts a pointer (delegate) to a procedure
It will remove all the event handler before invoking the procedure
Finally it would reinitialize the handlers on it's own after the job is done.
It may require a collection to all handler refering to it's events.
-> For that reason i'd let the class manage the handlers entiraly...
Alternativly you could put the 'SafePlot' idea in your main class. then you could manage the event handler there... but that is disputable
Well i can think of a few other ways to do this, but i'm cutting the brainstorming now!
If interested in one of these design solutions, give me a poke.
I have created a Form with Objects like Progressbar and Button.
I have also created Public library code outside my Form
I want to modify the Progressbar Control or the Button's Text from a Sub that is written in a library (I try to pass my Form as a parameter):
Public Shared Sub ModifyItems(ByRef _WhichForm As Form)
_WhichForm.MyProgressBar1.visible = True
End sub
Unfortunately, the code Is not recognizing the Progressbar name MyProgressBar1
Is there a way to modify the Progressbar Control on the Form directly in a Sub or Function that is written in a class library, not directly in the Form Code ?
This type of approach would generally fall under the umbrella of "bad practice". Having objects modifying each others members directly introduces tight coupling that makes for difficult code to extend, debug, and maintain.
Rather than trying to modify something from within the library, better to think in terms of notifying that something within the library has changed. You could, for example, raise an event within the library. Form1 could then listen for that event and make any changes to its components that are appropriate. This way Form1 is solely responsible for modifying its components and the library is solely responsible for announcing changes to its internal state.
To give a good example - if, say, you were to change your Form's progress bar component (maybe you find a better one out there) you suddenly introduce a breaking change into your library.
To use an event you might do something like :
Public Class MyLibrary
Event OnSomethingHappened()
Private Sub SomethingHappened()
RaiseEvent OnSomethingHappened()
End Sub
End Class
And then in your form :
Public Class Form1
Private WithEvents _myLibrary as New MyLibrary
Private Sub LibraryDidSomething() Handles _myLibrary.OnSomethingHappened
MyProgressBar1.Visible = True
End Sub
End Class
This nicely decouples any dependence on Form1 - the library exists as a self-contained entity and doesn't care who listens to its events.
If you want to do this with a shared class you can also use shared events - these must be connected programmatically as :
Public Class MyLibrary
Shared Event OnSomething()
Public Shared Sub DoSomething()
RaiseEvent OnSomething()
End Sub
End Class
in the form :
Public Class Form1
Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) _
Handles MyBase.Load
AddHandler MyLibrary.OnSomethingHappened, AddressOf LibDidSomething
End Sub
Private Sub Form1_FormClosed(sender As System.Object, e As _
System.Windows.Forms.FormClosedEventArgs) Handles MyBase.FormClosed
RemoveHandler MyLibrary.OnSomethingHappened, AddressOf LibDidSomething
End Sub
Private Sub LibDidSomething()
MyProgressBar1.Visible = True
End Sub
End Class
When programmatically adding events you must take care to remove them before disposing of the objects that have subscribed to them. In this case I have added the handler when the form loads and have removed it when the form closes. If you fail to remove an added handler then the form would not be garbage collected and this would cause a memory leak.
See here for more reading : Raising Events and Responding to Events (MSDN)
I've searched for the difference about the use of the keyword Handles instead of AddHandler, in VB.NET, but I'm unable to explain why this code doesn't work..
Imports System.Threading
Public Class MyClass_EventArgs
Inherits System.EventArgs
End Class
Public Class MyClass
Public Event MainThreadFinished(ByVal sender As Object, ByVal e As MyClass_EventArgs)
Private WithEvents MyEvents As MyClass
Private trd As Thread
Public Sub New()
'AddHandler MainThreadFinished, AddressOf Me.MyEvents_ThreadFinished
trd = New Thread(AddressOf mainThread)
trd.IsBackground = True
trd.Start()
RaiseEvent MainThreadFinished(Me, Nothing)
End Sub
Protected Overrides Sub Finalize()
trd.Abort()
End Sub
Protected Sub MyEvents_ThreadFinished(ByVal sender As Object, ByVal e As MyClass_EventArgs) _
Handles MyEvents.MainThreadFinished
MessageBox.Show("AAA")
End Sub
Private Sub mainThread()
RaiseEvent MainThreadFinished(Me, Nothing)
End Sub
End Class
Well, this code never respond to the events, but if I uncomment the followin line, the code works and the messagebox appear...
'AddHandler MainThreadFinished, AddressOf Me.MyEvents_ThreadFinished
Why does this happen?
It looks like you've made a fine discovery! Per Microsoft documentation, RaiseEvent Statement,
Non-shared events should not be raised within the constructor of the
class in which they are declared. Although such events do not cause
run-time errors, they may fail to be caught by associated event
handlers. Use the Shared modifier to create a shared event if you need
to raise an event from a constructor.
In other words, Microsoft says you shouldn't be doing what you're doing - and if you must, to use shared events.
In looking through other sources, I would say that the difference between AddHandler and Handles is a matter of syntactic sugar. You may want to look into how events are done in C# for more insight (such as in C# Events). Handles is used in conjunction with WithEvents as a way for an instance of a class to automatically subscribe to events (which is otherwise explicitly done with += in C# and with AddHander in VB.NET).
It would seem that your explicit AddHandler ensures that the event hookups are in place before the RaiseEvent, and so then it works as you wanted. I can only guess that without that, those event hookups weren't yet done - that is, it didn't work because of however the compiler inserts the code that performs the equivalent of AddHandler behind the scenes, by whatever design pattern the compiler writers deemed as appropriate. It would seem that the designers were well aware of this possible consequence, given their warning about this.