I have a program written in vb.net that contains a form. The form has 5 label controls and 1 button. I am using this program as my startup script file on my network (server 2008r2). When a user signs in to one of the servers the script executes and runs fine until it gets to the form.showdialog command. At that point nothing happens.
I have a try/catch like below:
Try
...write message1 to file in SQL database
Form1.ShowDialog()
...write message2 to file in SQL database
Catch ex As Exception
...write error message to file in an SQL database
End Try
message1 writes fine and that's it.
Now if I run the exe script file directly from one of the servers by double clicking on it the form displays fine.
If anyone can provide some insight I sure would appreciate it. This one has me stumped.
.ShowDialog causes the application to wait for the form being shown to no longer be shown. An example would be a prompt for a value, the form that threw the prompt would not progress past the .ShowDialog while the prompt remained open.
Since it sounds like you're wanting the code to progress without user involvement, my thought would be to:
- Move the code prior to Form1.ShowDialog into the Load code (Handles MyBase.Load) for Form1
Make sure Form1 is the Startup Form for the application
Add all code currently following Form1.ShowDialog to the .Shown event code for Form1
Related
I have an Access database where I have code on the On Load event of the main form to set focus to a textbox and load a 'new' record. The code is:
Private Sub Form_Load()
'Makes it so that when frmDiversion_Review loads, it defaults to a new record
DoCmd.GoToRecord , , acNewRec
Me!FromDate.SetFocus
End Sub
FromDate is an unbound date field used in a search/filter section on the header of the form.
I've split the database, and have an .accde file ready to go, but I've noticed that when I close Access when in the .accde file it gives me the following error:
"The expression On Load you entered as the event property setting produced the following error:
****NameOfDatabase**** can't move the focus to the control FromDate."
It does not give an error number.
The code is compiled, and I only get this error using the .accde file. I'm at a loss why the On Load event is even firing when I close Access. Any ideas?
A few weird scenarios may produce this (such as something relating to other forms being closed when you close out...) having references to this form that cause it to open. Hard to say from here.
But there is an easy out... just add this line at the start of the routine
On Error Resume Next
This is safe provided you know there are no real errors in the routine ever, excepting this annoying one that doesn't actually mean anything. If real errors can occur, you will no longer see them if you add this easy-out.
Personally, I'd prefer to find the cause and address it, not least because it seems other forms are trying to open this form while you're busy closing the app, which is an unsettling thought. But... when all else fails, it's a solution.
I have a VB6 application working with.
This application uses ODBC to access a Microsoft Access database.
I am sure that the database string is correct as the database contains the information used to login and the login works just fine. I also have the same string at every instance.
However, at a certain point the ODBC driver error-"Data source name not found and no default driver specified" appears...The issue is:
This occurs whenever I press a specific button. This button opens a form:
Private sub Munubttn_Click()
frmLog.Show
End Sub
However, in the form frmLog, I placed a message box as the first command under the Form_Load() sub. Now whenever the button is clicked, I get the error, just before the message box. As such, I do not know where this error originates. So I suppose the question is, what code does the form execute just before it loads? Any help would be appreciated.
So I suppose the question is, what code does the form execute just before it loads?
The only code that would be executed would be the class initialize sub. Given your described scenario, the problematic logic is likely in a Class_Initialize sub within the frmLog Form.
I have a quick question.
I want to run some come when my application exits, wherever in the winform application it may be. The reason is that the user adds/changes data in the application in different forms, and I have it set to save different data to My.Settings. When the application exits, I want it all to be saved to a text file, to be loaded when the application is next started up. I cannot save to text file whenever the data is changed because it is changing too many times, so for ease of access, I save it My.Settings.
I know how to save the data to a text file, I just want to know how can I have it run the code to save data to the text file WHEN the application is exiting.
VB allows you to add code to perform tasks when your application Starts or Shuts down. To access these, go to Project Properties -> Application Click "View Application Events".
This will open a file very much like a form code window. From the left/Declarations menu select MyApplication Events, then select ShutDown from the event list. This will bring up this:
Private Sub MyApplication_Shutdown(sender As Object,
e As EventArgs) Handles Me.Shutdown
' your code
' to executes when the application is shutting down
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.).