VB.NET program.
While developing on Visual Studio Express 2010, there are two buttons: Start Debugging, and Stop Debugging.
Well, while debugging, I close my application (the red X button). However, when I look back at Visual Studio, it seems to still be in debugging mode (the Start button is disabled, and the Stop button is enabled). So I have to manually press the Stop button.
I remember it was not like this before.
Perhaps it is because my application uses multiple forms or something? Then I am probably missing something rather important... Any ideas?
You've got something open somewhere. You can force the entire app to quit by adding
End
in the form's FormClosed event:
Private Sub Form1_FormClosed(sender As Object, e As System.Windows.Forms.FormClosedEventArgs) Handles Me.FormClosed
End
End Sub
Are you doing any threading? Shutting down your primary app leaving threads running will cause what you are seeing. Also app design can cause what you are seeing. You can start your vb.net app running a "main" procedure, but if you don't provide an exit for it, the app will continue to run.
Ensure that all hidden forms (if any) are closed, properly dispose all objects.
If you are hiding any form and forgot to close it in your application this scenario may happen. Or if you are using threading in your application and they are not terminating properly then also it happens.
Related
I have an app built in VB in Visual Studio 2012 that works absolutely fine on my windows 10 desktop, but as soon as i use it on my windows 10 tablet i see a couple of issues :
1) any forms that were intended to be smaller than full screen are shown fullscreen anyway (almost as if you're not allowed any windows less than full screen) i can live with that if need be, but surely theres a way around it?
2) - the most important one - for some strange reason, i start my app, and when i click on a button let's say it opens form 6. once i finish what i'm doing the code closes the form 6, but the previous form is now hidden and all you see is the desktop. ie it's still running, it just lost its focus and must be selected again. I understand i could set the focus to the underlying form before closing form 6, but here's the problem : it can be one of several different forms calling form 6..... so how do i make the app stay aware of what form called form6 so that when done i can return focus there?
this doesnt seem to be a problem on the desktop so i've never encountered it before. i hope one of you experts has dealt with this before
I don't have enough points yet to comment. My guess for #1 is either resolution or DPI differences between the 2 screens, and I don't have experience with the latter.
As for #2 and keeping the form aware of who called it, this is how I do it, which may not be the best solution, of course. ;)
First any form that can have multiple callers has a variable defined like
Dim callingForm As New Form
I typically create an Initialize routine to handle as much as possible before loading a form and this routine is called with the parent form (Me) as a parameter.
Dim frm As New frmClient
frm.Initialize(Me)
frm.Show()
Me.Hide()
In Initialize, callingForm is set to the parent
Public Sub Initialize(parent As Form)
callingForm = parent
'whatever else you need to do to init...
End Sub
Then when you exit the form...
Private Sub exitForm()
'whatever other closing stuff you need to do...
callingForm.Show()
Me.Close()
End Sub
That should get you started.
fyi for anyone encountering this problem, i solved it myself and it didn't require any coding. It was a difference between how vb apps act when the tablet is in "TABLET" mode, and when tablet mode is switched off. So all that needed doing is switching off enhanced tablet mode in the windows 10 settings
I am recently out of school, working my first job as a programmer. We have a user-reported bug that is occurring when our application timeout timer closes the application. I'm pretty sure I've narrowed it down, but am curious as to why the original programmer would have done this, if it's good coding practice, and if so, I am curious if anyone has a way to handle this. We are getting a post-closing system error, as it occurs after the main form closes, so we don't get any exception log input.
The close functionality of the timeoutTimer_tick handler does the following:
For iCount As Int16 = Application.OpenForms.Count - 1 To 0 Step -1
Try
Application.OpenForms(iCount).Close()
Catch
End Try
Next
Try
Application.Exit()
Catch ex As Exception
End Try
The program is set with the application property to close when the main form closes (not ALL open forms are closed). This makes me wonder why we're looping through each form and closing them individually, and then calling Application.Exit()
I'm pretty sure our error is because of the Application.Exit call after all open forms are closed. It doesn't see the main form, as it was closed during the loop, and throws an error. I feel like we should be using one or the other, but not both.
Any input or advice? Which is better, or are either better (or should this code work without error, and I am simply wrong).
Thanks
In WinForms you have a Shutdown Mode setting (Project Properties>Application Tab)
This allows you to specify When startup form closes or When last form closes
So logically you should not need Application.Exit .If you do then there is some other object hanging around in memory that you need to dispose of (something started on a thread / background worker etc)
So If you have the startup form setting:
[StartupFormName].Close
or if you have the last form setting:
Do While My.Application.OpenForms.Count > 0
My.Application.OpenForms(0).Close()
Loop
I have a program where I need to do some initial work before calling the form, so I disabled the Application Framework setting and wrote my own Main function with a call to Application.Run(myForm) when it's time to run the form.
Everything was working fine, no problems, but now I have need of some other service before opening the form. Rather than add all that code to this program, it has all been moved into its own executable. This second program can edit files that the first program will use, so I need the first program to wait so that it will read up those changes (should they be made). I suppose could just as easily use the Shell function, but for various reasons I'm creating my own Process object and calling it/waiting on it through that.
Anyway, I make this call to the second program some time before the Application.Run call. The first program waits its turn, and I can interact with the second program successfully, no trouble at all. But when it's done, the window for the first program is hidden behind any other windows that are on the screen. This doesn't happen in XP, only in Vista (and maybe 7, but I haven't confirmed yet). I've already tried manually forcing the form to appear in front, minimize then maximize, get focus, etc, but nothing brings it to the front unless the user manually clicks on it with the mouse.
What am I doing wrong? Why does this behavior occur? I know it has something to do with waiting for the executable to finish, because if I don't force the first program to wait everything is fine (other than it not waiting). I can circumvent the issue by calling the second program in the Load event of the form, but then I have to read the file a second time to catch the changes instead of reading it once, and it also looks bad because the form is being drawn really slowly while the second program is sitting there.
If anyone has any input, I'd appreciate it.
This isn't really an answer to why you're experiencing this behaviour, but a simple workaround would be to temporarily set the form's TopMost property to True in the load event. Then, depending on how intrusive you want that to be, you could either reset it under a short timer or wait for say the MouseEnter event to fire.
There are another topic in this site about that, but I not got the link. This problem seems be a bug into .NET framework. The API below (VB.NET example) works for me in windows XP and 8.1. Don't tested in other versions of Windows.
<Runtime.InteropServices.DllImport("user32")> _
Public Shared Function SetForegroundWindow(hwnd As IntPtr) As Integer
End Function
Private Sub Form_Load(sender As Object, e As EventArgs) Handles Me.Load
SetForegroundWindow(Handle)
End Sub
I've inherited some VB.net code. My task is to find out why it isn't working. I have 2 applications. The first one
is run as a service, infinitely checking a table to see if there are any tasks to be handled. If it finds one, its supposed to fire off the second application to handle the task then returns to the loop and checks for another. Both these applications are forms but they do not show any windows. The problem I'm having is after the second application is finished, the first application never gets a signal it is done so it is waiting forever, thus it can't move onto the next task. If I go into TaskManager and kill the second application, the first one gets that notification and proceeds as it should. Below is how I am creating the process and waiting for it. I've tried several different ways of creating and waiting for the process (using a Shell/OpenProcess, WaitForSingleObject,etc) and I can't get it to work. I've searched all over the internet, StackOverflow and the MSDN site but nothing I've tried works. I've been messing with this for 2 days!!
Form 1 Load:
Dim ProcessProperties As New ProcessStartInfo
ProcessProperties.FileName = strExeFullPath
ProcessProperties.Arguments = " /project " & l_project
ProcessProperties.CreateNoWindow = True
Dim myProcess As Process = Process.Start(ProcessProperties)
myProcess.WaitForExit()
When Form2 is finished, it does a Me.Close() and Exit Sub in the load subroutine but the process is still showing in the TaskManager and never returns to Form1 so Form1 is in WaitForExit forever. I've tried closing every open file and connection and setting them to Nothing in Form2, Me.Dispose,etc. I've tried Application.Exit as the last line of Form2. That stupid thing will not die!! Why won't it DIE!!??!!
What am I missing?
If I go into TaskManager and kill the second application, the first one gets that notification
Keep your eyes on the ball, the real problem is that this second application is not exiting by itself. And thus myProcess.WaitForExit() isn't going to return. So this is not a problem in your code snippet.
Why the 2nd app doesn't want to quit is completely unclear from your question. Given that it is a Windows Forms app, do keep in mind that there is nobody to click the Close button of the form. Application.Exit() should make it stop, Environment.Exit() is a rude abort that cannot be veto-ed by a FormClosing event handler.
Anyway use this:
ProcessProperties.Arguments = String.Format("/project {0}", 1_project)
No leading space is required and code becomes more readable.
Cheers!
I suspect Form2 is trying to show some modal dialog (maybe a message box, maybe an unhandled exception box) before quitting. Since App2 is launched by App1, which is a service, Form2 cannot interact with the desktop and just sits there waiting for a button click that will never happen.
Try to allow the App1 service to interact with the desktop (you can find that option on the Log On tab of the service properties dialog box) and check if Form2 actually pops up a dialog before quitting.
Is there any reason to start a GUI program (application for Windows) written in VB.NET in the Sub Main of a module rather than directly in a form?
EDIT: The program won't take any command line parameters and it will be executed as a GUI program always.
The primary reason for using Main() in VB .NET 1.x was for adding code that needed to run before any forms were loaded. For example, you might want to detect whether an instance of your Windows Forms app was already loaded. Or you might want to intercept any unhandled exception for the AppDomain:
AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf MyExceptionFilter
But the next version of VB and Visual Studio 2005 introduced a new Application model that made Main() unnecessary in most scenarios. You can now intercept the My.Application.Startup event to add code that needs to run before any forms are loaded.
Note that the code for the Startup event handler is stored in the ApplicationEvents.vb file, which is hidden by default.
You can do it either way, but you should really only keep code in the form that is directly related to the operations and user interface elements on that form. Application startup code isn't related to UI, normally concerned with splash screens, checking network connectivity, verifying a single instance only, setting up user configuration settings, and so on.
After the above items (or the appropriate initialization code for your app) are complete, Sub Main can create an instance of the main form, then show it so the user can begin interacting with your application.
This separates startup code from your form code. Later, when you're maintaining the application, you'll be glad you separated the two.
Yes, and I have done it a few times.
One reason is, that if your app is COM EXE (speaking now from a VB6 point of view) then you want to be able to detect in what context the EXE is being called (being launched or being spoken to by some other app).
For example:
Sub Main()
If App.StartMode = vbSModeAutomation Then
...
Else
...
End If
End Sub
Another is if you want your app to be able to handle any command line parameters.
For example:
Sub Main()
If App.PrevInstance Then End
If InStr(Command, "/s") > 0 Then
Form1.Show
ElseIf InStr(Command, "/p") > 0 Then
LoadPicture ("c:\windows\Zapotec.bmp")
End If
End Sub
(from one of my attempts to make a screen saver)
No, if you always want to show that form.
Yes, if you sometimes want to use your app without GUI, just using command line.
Yes, if I want to display different forms depending on some parameter (in a file, on a remote server, etc.).