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
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 have made a game installer which copies some files from the installer to the game directory. However, when I click the button which runs the sub below, the program freezes until the action is complete.
Private Sub InstallGameFilesClicked(sender as object, e as eventargs) Handles InstallGmF.click
My.computer.filesystem.copydirectory(environment.currentdirectory & "\res\gameFiles", installDir & "\res\")
End Sub
(installDir variable is a string set by the user previously in the program and determines the place where the game is going to be installed)
What I would like to have is for the program not to freeze when the button is clicked...
Is there a way of doing this?
Thanks, Rodit
An easy way of executing tasks in the background is to use the BackgroundWorker. See How to: Use a Background Worker. The BackgroundWorker also allows you to give feedback to the UI in order to display a progress bar for instance.
You should learn how to use a background worker object. It will run the copying in a different process than the one that the main part of your program uses and thus not cause it to freeze. The background worker object can be found in the toolbox under components.
BackgroundWorker1
A word of warning, you have to know how to use it to get it to work correctly. When it is done, it will return an event to the main part of your program and you should use that to signal the user that the copy process is complete, etc. Just search for examples on how this works.
I have a vb.net based windows application, where when "GO" button is clicked a bunch of data is loaded into DB. So in my application as soon as "GO" button is clicked I want to just disable it and would like to enable it back when the uploading has completed.
Now in my specific method for btnGo_Click() I have:
btnGo.Enabled = False
as first line and
btnGo.Enabled = True
as last line in the same method.
But I fail to understand why the "GO" though appears as being disabled still allows click when processing is going on. Also if I remove the last line, it gets disabled permanently and doesn't allow the click event.
Kindly suggest what am I doing wrong?
Edit (Dated: 25th Jan 2012): I made changes as suggested by our collegues, but I am facing a new issue here. I am facing an issue where the textbox gets updated but not always. I have updated my textbox in "_ProgressChanged" event of the background worker thread. In my case if there is 10 records uploaded. Then there are 10 lines of updates that are expected in the texbox. But only few lines are shown in the textbox. Is it the repaint issue again? Kindly suggest...Because all other things are done as per your suggestion
You're not doing anything wrong. The problem is that the UI doesn't get updated until the code inside of your event handler method finishes executing. Then, the button is disabled and immediately enabled in rapid sequence.
That explains why if you forget to reenable the button control at the end of the event handler method, it is still disabled—because you told it to disable the button in the first line of the method.
This is a classic case of why you should never perform long-running computational tasks inside of an event handler method, because it blocks the UI from being updated. The computation actually needs to happen on a separate thread. But don't try to create the thread manually, and definitely don't try to update your UI from a separate thread. Instead, use the BackgroundWorker component to handle all of this for you automatically. The linked MSDN documentation has a great sample on how to use it.
Disable the button before starting the BackgroundWorker, and then re-enable it in its Completed event, signaling the completion of your database load.
Since you're trying to execute a function that can take some time, I'd advise you to make use of threading. In .NET there's a BackgroundWorker component which is excellent for performing tasks asynchronous.
On button click, invoke the BackgroundWorker like this:
if not bgwWorker.IsBusy then
btnGo.enabled = false
bgwWorker.RunWorkerAsync()
end if
And use the completed event to enable the button again:
Private Sub bgwWorker_DoWork(ByVal sender As System.Object, _
ByVal e As System.ComponentModel.DoWorkEventArgs) _
Handles bgwWorker.DoWork
' Do your things
End Sub
Private Sub bgwWorker_RunWorkerCompleted(ByVal sender As System.Object, _
ByVal e As System.ComponentModel.RunWorkerCompletedEventArgs) _
Handles bgwWorker.RunWorkerCompleted
' Called when the BackgroundWorker is completed.
btnGo.enabled = true
End Sub
In the example above, I've used bgwWorker as the instance of a BackgroundWorker.
The button click event is handled as soon as the UI thread has idle time.
After you disable your button, the UI thread is keept busy by your code. At the end of your method, you re-enable the button, and after that you exit the method and allow for idle time.
As a consequence, the button will already be enabled at the point in time where the click event is handled, so your click is "recognized".
The solution is, as others already suggested, to use a Backgroundworker.
Dont try to use doEvents() as a solution (never do), since this would be prone to introduce other subtle problems. That said, you can prove the above explanation with some experimental doEvents in your code. You will see that the click is discarded if a doEvents is performed before the button gets re-enabled. On the other hand, performing a doEvents directly after the button.disable (to "update the GUI") will not help if it is executed before the click.
If your btnGo_Click() is ran inside main thread, UI could not be updated correctly inside a time-consuming task.
The best way you can do what you need is running your method in a BackgroundWorker.
I just tried disabling a button, Updateing the form, Sleeping, and enabling it again. It still performed the click (A click that was done while it "slept" with the button disabled) after it was enabled.
I guess forms "remember" clicks.
(EDIT: I did this in C#.)
It's usually not a good idea to manage the state of a submit button. Instead, perform validation on submit.
I would like to add 2 enhancements to the answer generally described here which is to 'do the work in another thread'.
Ensure button.enable=true always gets called
1.a. You should use a try block in button_click . If there is an error in launching the thread, CATCH should re-enable the button.
1.b. The task complete call back should also ensure the button is enabled using try/catch/finally
1.c The task timeout should also re-enable the button
A common error based on exactly the situation described here is rapid-clicker-person clicks the button twice in rapid succession.
This is possible because its possible, even if unlikely, that 2 click messages get queued and processed before the button is disabled. You can not assume the events happen synchronously.
IMHO a best practice is to use a static variable. Initialize it to 0. Set it to one as the very first statement and set it to 0 following the guidelines in POINT 1.
The second statement in button click should simply RETURN/EXIT if the value > 0
If you are using a worker thread, the static variable may have to be located in that code. I would not advise making it a form level variable.
I had a slightly different issue not being able to call click.
I have a routine that turns the UI on/off based on a validation routine.
i will say that I disagree w/ the suggestion to do validation in the submit. The button should not be enabled if we are able to tell the form is invalid.
My issue was that I was calling the validation from several places. One of the calls was the CustomCellDraw event of a grid which was firing very frequently.
So while it appeared that I was simply disabling/enabling the button a few times, I really was doing this almost continually.
I was able to trouble shoot by placing a label on the form and kind of doing a console.log thing. I immediately realized button.Enabled was flickering, which led me down the correct trouble shooting path.
I realize this addresses a different root cause than op described. But it does address the problem the op describes.
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.).