I have a console application that is built in VB.Net. Now I have a timer in that application. All I want to do is at a particyualr time i will call another exe (which is built in VB 6.0) and again get the control back to this console application.
Now what is happening is that I am being able to call the second exe from the console application , but then the control is not returning back to the same console application.
Any help will be much appreciated.
Thank you in advance
Process.Start(myProgramPathAndFileName)
This should create a new process and return control to your console app.
You can do more with this process by storing the return value:
MyProcess = Process.Start(myProgramPathAndFilename)
Then call this when your application exits
MyProcess.Kill
See: http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx for more info on processes.
See: .NET Console Application Exit Event for information on handling Application Exit as an event.
Related
I have experienced this behavior in my automation application: when I "click" a button by calling the InvokePattern.Invoke() method everything stops until the handler of the click event inside the automated application finishes.
While this can make some thing simple (for example I don't have to write tons of code to wait for a dialog with progress bar to disappear, because I simply get the control back when everything is done), but I can't do anything else. It even blocks the access to the Automation API in another thread where it continues after the click handler is done.
This causes problems when click handler in the automated application opens a modal dialog, then I can't do anything, the access to the application through automation API is blocked until the dialog is manually closed.
Has anybody solved this somehow and can help me?
Thanks,
Karel
PS: Reference source is saying this:
Request that the control initiate its action.
/// Should return immediately without blocking.
/// There is no way to determine what happened, when it happend, or whether
/// anything happened at all
public void Invoke() { ... }
Edit: It works perfectly when automating Windows notepad application which is not a .NET application. And it does not work for a Notepad clone (C# WinForms aplication).
We have an internally developed VB.Net Windows Forms Application that handles all our Auto-Updating for our other software applications. Whenever I run the application in Windows 10, the application starts under the "Background Processes" section of the Task Manager. The only way I can get it to run in the foreground is to run it as an Administrator even though I'm an Admin on the VM and my UAC settings are turned all the way down. This doesn't happen in Windows 7 or 8 so I'm wondering if there's something I'm doing wrong or something about Windows 10 that's changed where it has to be run as an Admin. Our other applications don't seem to have this issue, it's just specifically this one application for some reason but I can't seem to figure out what's different.
So I put some more error handling in and it sounds like #xfx was onto the right idea. The application is erring when it starts up because it can't register the URL of the WCF service so it never got to the point where it was displaying the form. Once I manually registered the URL of the WCF service and ran the application as an Admin, it displayed and worked like normal.
This is because of the way the project has been configured in Visual Studio.
Here's how to create an application that behaves like a background process:
In the Project settings dialog, disable the Enable application framework option
Next, change the Startup object to Sub Main
Finally, add a Module to the project and add the following code:
Module Module1
Sub Main()
Application.Run()
End Sub
End Module
If you run the application (not from within the IDE, but directly) it will behave just like the one you describe.
The application will remain as a background process as long as it doesn't display a Form. As soon as one is displayed, you will see that Task Manager moves the process from the Background processes list to the Apps list.
To test this, just change the code in the Module for this version:
Imports System.Threading
Module Module1
Sub Main()
Dim tmp As New Thread(Sub()
Thread.Sleep(3000)
Using f As New Form1()
f.ShowDialog()
End Using
End Sub)
tmp.Start()
Application.Run()
End Sub
End Module
The application will start as a background process and 3 seconds later will display form, becoming a foreground process.
I am working on application which will have to be executed from windows task scheduler once a day. It is written in VB.net and right now it runs when RUN button is clicked. But how can I tell the windows task scheduler which subroutine to run when the application starts? Do I have to place the code to be executed into form load? Or can I pass an argument or something similar when calling the application in task scheduler?
Anything to be run by the task scheduler should not interact with the user and should be written as a console application and not a Windows Form application.
Console Application
Sub Main ()
Dim taskToSchedule as New TaskToSchedule
taskToSchedule.DoStuff()
End Sub
If you also need it to be run by a user then move the task functionality into a class library and invoke that from the button and the console app Sub Main.
Windows Form
Sub ButtonClick ()
Dim taskToSchedule as New TaskToSchedule
taskToSchedule.DoStuff()
End Sub
In VB 2008, I am using the class 'process' to launch and external application with a few parameters. Does anybody knows how can I send it programmatically to second monitor?
Also, is there any way to know how many monitors are activated?
Thanks.
You can locate your form on a different screen.
form.Location = Screen.AllScreens(1).Bounds.Location + new Point(100, 100)
When you launch an application, use the Process Handle to get the Window (hWnd). It's this hWnd value that windows API uses.
You will need to use the SetWindowRect method imported from User32.dll (see last link)
See also
Screen Class
VB .NET Dual Monitor
Get Window Handles Associated With Process in vb.net
Egghead Cage - hwnd position
MSDN - SetWindowRect API Call
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.).