I have the problem, I'm in a network, where everyone sends messages through msg. Through it's really annoying, I thought about killing the messageboxes process. Running under csrss.exe thats not possible. When I looked through the taskmanager I noticed, when opening the tree structure of the csrss.exe, there was the messagebox and I could kill it. Has anyone any idea, how to do that in Visual Basic.
A simple web search led me to this question, which has some good answers already.
With a little work, I came up with this solution. It find the process by name (csrss), then filters by window title (Message from).
Sub Main()
killProcesses("csrss", "Message from")
End Sub
Private Sub killProcesses(processName As String, mainWindowTitle As String)
Dim processes = Process.GetProcesses().
Where(Function(p) p.ProcessName.Contains(processName)).
Where(Function(p) p.MainWindowTitle.Contains(mainWindowTitle))
' (Where clauses can be combined into one of course)
For Each p In processes
p.CloseMainWindow()
Next
End Sub
It works like this. Send a message
C:\Users\djv>msg djv hey whats up
Get a message
Here is the task
And what the code sees
It is closed upon the p.CloseMainWindow() call. It will also close any other window which matches the description, since it's not limited to one. This should satisfy your requirement.
Just so the question hast a proper answer, I found a solution using the win32 api (PInvokes) specifically the user32.dll. It provides methods like GetWindow, GetWindowThreadProcessId and CloseWindow, which solved my problem.
Related
In the past I've usually added the following line to the KeyDown sub in order to end my applications:
If e.KeyCode = Keys.Escape Then End
However, upon reading the documentation on what End actually does, it turns out that it probably is one of the worst ways to end the application in terms of releasing resources, etc.
So now I'm trying to find the recommended way to terminate the application which will properly handle all resources, etc. I've found these two questions on SO (here and
here) but I can't conclude what the right answer actually is.
The accepted answer on the first link says that applying Close() to all forms is the correct way and will release all resources used correctly. This isn't convenient in applications with multiple forms, and further down Application.Exit() is suggested, and even:
Application.Exit()
End
which will definitely make sure the program ends even if the first line fails.
On the other hand, the accepted answer on the second link says "you should never have to call Application.Exit() in a properly-designed application", contradicting the above and an answer further down which says Application.Exit() calls Close() on all forms in later versions of .Net.
This has lead me to confusion — what is wrong with Application.Exit()?
If there is no problem with it, then am I right in thinking the best one to go with is:
Application.Exit()
End
or is that overdoing it? Otherwise, when does Application.Exit() fail to work (except when I write code which cancels it)?
Note: Although this question applies to all programs I make, including ones with multiple forms, I recently have started using Sockets (with the TcpClient/Listener classes) to make connections between computers and would appreciate any additional information relating to this when terminating the program in the middle of a connection. A comment in my recent question assures me that calling Socket.Close() isn't even necessary, but now I realise that this may not be completely true since I was using End to terminate before.
Application.Exit posts an exit message to all message loops for that application.
It's a perfectly acceptable way of closing an application and will cause all forms to attempt to shutdown. Individual forms can override this behaviour, for instance if they have unsaved work. This will leave your application running afterward so you need to decide if that needs to be handled.
Saying that I only use it if an external actor needs to shutdown my application. Otherwise I leave the app to exit when its main form closes.
You also need to consider the state of any foreground threads you have as these can allow all your forms to close but leave the thread processing in the background.
End is a very brute force technique and should be used as a last resot. A well designed application should be able to shutdown by closing the forms or by calling application.exit. I have used the approach in the past of launching a timer which will call End just before I call Application.Exit ... at least I give it a chance to complete gracefully.
Note: Application.Exit doesn't block. So Application.Exit : End might as well be End which is not ideal.
Here's the timer I use:
Dim forceExitTimer = New Threading.Timer(Sub() End, Nothing, 2500, Timeout.Infinite)
Application.Exit()
I currently have made an all in one peer to peer 'chat' program. It currently uses a timer to receive messages, and a client to send them to other people running the program. I would really like to make this whole system async so I stop getting complaints of the main executable freezing and such.
I have pasted all of my code(VB.net) here: http://pastebin.com/EcrtCgVc
Could someone assist me in making this system faster, async, or done better.
If you would like a link to the dropbox of the full source, I can provide this also.
I would suggest you to take a look at this example project:
Asynchronous Server Socket Example
http://msdn.microsoft.com/en-us/library/fx6588te%28v=vs.110%29.aspx
You can use it together with this example:
Asynchronous Client Socket Example
http://msdn.microsoft.com/en-us/library/bew39x2a%28v=vs.110%29.aspx
You may need to use async methods in your server code and you may use Delegate Sub to make your server run in another thread, so main thread(UI) will be still responsive.
http://msdn.microsoft.com/en-us/library/ms172879.aspx
Without looking at your code, I am also working with socket programming.
"Do not mix GUI code with business code."
Like jgauffin said, you should not combine code that run in the background with the GUI.
For example, if you're using a socket to accept data, or connections, you must run that method on a new thread.
Example...
Public Sub YourMainSub()
Dim threadOne As New System.Threading.Thread(AddressOf ListenCode)
threadOne.Start()
'Put other code here.....
End Sub
Public Sub ListenCode()
Dim newPerson = yourServer.Accept()
'Or
Dim newData = yourServer.Receive()
End Sub
Sorry if the code isn't exactly correct. I typed that by memory.
OK guys, what's going on here?
In this VB code:
Module Module1
Sub Main()
If MsgBox("Restart?", MsgBoxStyle.OkCancel) = MsgBoxResult.Ok Then
Application.Restart()
MsgBox("restarting")
Else
MsgBox("Cancel")
End If
End Sub
End Module
If this code is contained within a module, Application.Restart does not end the running application till the End Sub is hit. Any code that appears before then is executed - eg the 'Restarting' messagebox appears.
However, if the equivalent code is run within a form then Application.Restart terminates the running application immediately.
(Both cases correctly start a new instance). This behaviour does not appear to be documented anywhere - the implication in the docs is that it's synonymous with 'End' as far as the termination of the running instance is concerned. Am I missing something?
The best way to answer these questions it to look at the code itself using Reflector (or Microsoft's free for debugging code, when it is available).
With Reflector, you can see (in .NET Framework 4.0) System.Windows.Forms.Application.Restart looks for four different types of applications:
the initial check that Assembly.GetEntryAssembly is Nothing, throwing a NotSupportedException if it is;
the Process.GetCurrentProcess.MainModule.FileName is ieexec.exe in the same folder as the current .NET Framework (specifically the folder where the module defining Object is);
ApplicationDeployment.IsNetworkDeployed is True; and
the general case.
All three supported cases determine the method to start the process again, calls Application.ExitInternal and starts the process again.
Application.ExitInternal closes open forms, including the check for a form attempting to abort the close by setting FormClosingEventArgs.Cancel to True. If no form attempts to cancel, the forms are closed and, using ThreadContext.ExitApplication, all ThreadConnexts are cleaned up (Disposed or their ApplicationContext.ExitThread is called).
NB No Thread.Abort is called, so threads are NOT explicitly ended in any way. Also the Windows.Forms ModalApplicationContext, does not even call the ThreadExit "event" that a normal ApplicationContext does.
(Note that all three supported cases in Application.Restart ignore the result of Application.ExitInternal, so if a form does attempt to abort all that happens is any other forms don't get a chance to close, and the ThreadContexts are not cleaned up!)
Importantly for your question, it does NOT attempt to actually exit the current threads or the entire application (other than closing open forms and thread contexts).
However, by the time your MsgBox("restarting") executes the new application has been started.
You need to manually exit the application after calling Application.Restart. In the case of "run[ing] within a form" (you don't show the code where you tested this) either the form is closed and that is what you considered as the current application ending, or extra stuff that Windows.Forms (or VB) sets up means the application is exited by one of the "events" that throw when the clean up that does occur runs.
In other words, before testing it I expected the MsgBox to appear even when this code is in say the Click event of a form, with the form disappearing first, and the application restarting at the same time.
Having tested it, the MsgBox tries to appear, as I hear the beep that corresponds to it, and if I comment it out the beep does not occur. So something causes the application to exit even though it should have a message box open, and even putting a MsgBox in a Finally outside of the Application.Run does not appear on a Restart. (Note a similar effect is seen if you call MsgBox after Application.Exit.)
So something set up by Windows.Forms (or VB) does actually call something like Environment.Exit which calls the Win32Api ExitProcess and does not regard Finally or call Dispose or Finalize.
Note the Application.Restart documentation implies it is not for Console Applications though it currently works fine (except for the not quitting straight away, which is not implied by Application.Exit).
I am able to restart the application by closing and disposing all open forms, except the one that is calling.
For j As Integer = Application.OpenForms.Count - 1 To 0 Step -1
Dim frm = Application.OpenForms(j)
If frm.Text <> callingForm.Text Then
frm.Close()
frm.Dispose()
End If
Next
Application.Restart()
This is going to be, admittedly, a bit of a guess based on some fairly top-level reading I've done about Application.Restart(), but I think this is occurring due to the way Restart operates internally.
I think Restart() tries to do as much "intelligent" cleanup as it can for a process that is being terminated, and in what may be considered a fairly simplistic implementation, tracks certain of the things to be "cleaned up," possibly calling Dispose() on them (if applicable), which normally is a reasonable step to take. In your case, I'm going to make the guess that a background thread, or form, holds a reference to something - can't say what - that prevents the code from shutting down. It may become aware that it is executing inside a method, and wants to give that method a chance to complete before killing it - waiting on the completion of that sub/method.
I've seen other instances of Restart actually causing a really strange "Collection was Modified" error when no collection was involved. That's suggesting to me, probably naively, that the internal cleanup Restart is trying to achieve is reposed in a simple list, but in certain circumstances, the cleanup modifies the element in an unexpected way, a way that modifies the collection, causes the exception to be thrown, and aborts the exit/restart.
My company's main software package includes a hefty configuration library which loads on startup. This config library includes some mandatory settings which, if not supplied (via command line arguments), cause the entire application to exit.
This has never been an issue for our users, who launch the software via scripts which have the needed command line arguments supplied automatically. But sometimes when debugging our software we developers forget to specify the necessary arguments in Visual Studio's debug options; it's then very annoying to be greeted with the message Config specification invalid -- missing required parameters X, Y, and Z -- shutting down (I'm paraphrasing, of course).
It's not really a big deal, just an annoyance. Still, I felt it worthwhile to throw together a little form to make this process a little less painful; it notifies the user which parameters are missing and allows him/her to specify values for those parameters directly on the form, without having to restart the application.
My intentions were good (I think?), but it seems I can't get this solution to actually work. The problem is that after I've launched our software with missing settings, the form pops up and prompts me as expected; but after I've entered the required parameters and it's time for the application to "really" start, I get this InvalidOperationException:
SetCompatibleTextRenderingDefault must
be called before the first
IWin32Window object is created in the
application.
I think I understand what's going on here: the VB.NET project I'm working on is doing something like this "behind the scenes"*:
Sub Main()
Application.EnableVisualStyles()
Application.SetCompatibleTextRenderingDefault(False)
Application.Run(New MainForm)
End Sub
That call to SetCompatibleTextRenderingDefault is, apparently, throwing an exception because a form was already created and displayed prior to its execution.
Is there any way around this? Is there perhaps a more "proper" solution to this problem that I'm not thinking of (i.e., should I not be trying to collect user input via a form at all)?
*This is a best guess based on what I've seen in C# WinForms projects. Strangely, unless I'm missing something, it seems that VB.NET WinForms projects completely hide this from the developer.
Do make sure that you have the application framework option turned off and Sub Main selected as the starting method. Make it look similar to this:
Sub Main(ByVal args() As String)
Application.EnableVisualStyles()
Application.SetCompatibleTextRenderingDefault(False)
If args.Length = 0 Then
Using dlg As New OptionsDialog
If dlg.ShowDialog <> DialogResult.OK Then Return
'' Use dlg result...
End Using
End If
Application.Run(New MainForm)
End Sub
Perhaps you could use the static Debugger.IsAttached (or even a #DEBUG directive) in your program's "main" function that feeds in some input file (say an XML file) into your parsed args collection instead?
I'm using the MAPI code by Dave Brooks.
I am attempting to programatically send out a Crystal Report that is generated.
When I run through the code without threading everything runs fine. The problem is when I use threading I get the return error "General MAPI failure [2]".
I have never used threading before and understand that there are dangers involved. Can anyone provide any insight into this issue? NOTE: I've removed exception handling to make the code clearer.
Private Sub RunReport()
SetParameters()
SaveReportFile()
Dim operation As New ThreadStart(AddressOf SendEmail)
Dim theThread As New Thread(operation)
theThread.Start()
End Sub
Public Sub SendEmail()
Dim m As MAPI
m = New MAPI()
Dim email As String
For Each email In emailAddress
m.AddRecipientBCC(email)
Next email
m.AddAttachment(#"c:\temp\report.pdf")
m.SendMailPopup("Requested Report", "")
End Sub
A very late answer, but thought I'd add it anyway as I just encountered this and couldn't find an answer elsewhere.
You need to set your thread's appartment state to STA before it is started using:
theThread.SetApartmentState(ApartmentState.STA);
Note that threads from the threadpool (e.g. used by BackgroundWorker component) are MTA.
I encountered this same error (General MAPI failure [2]) and came across this solution early in my debugging; however, the cause for my error was due to running my application as administrator while outlook was running as my user. I had a hard time finding the cause of my error so hopefully this will help someone on the same search as me.
If the above answer doesn't solve your problem, try running your application without elevated privileges if possible or find a way to call MAPI using user impersonation.