Launch an application and send it to second monitor - vb.net

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

Related

Is there a way or event to retrieve command line arguments on runtime

so i'm trying to make a media player so far i'm in the final stage to publish my media player for poeple to download it i'm just having an issue where i need to capture command line argument on runtime , so far i've checked the run only one instance of the app and i can recieve command line argument when using Open With from windows explorer it works but what i need to do is to be able to recive command line arguments on runtime , assume you're using my app , you're listening to music and you found a music you love on a folder on your pc , you're so lazy to switch to the app and use the open file button you just want to double click the song and start listening , now if the app is closed when you double click the song it will play with no problem but if the app is running it won't play windows will just switch to the app.
So the question is : is there an event or a way to catch if command line argument is passed to the app on runtime ?
Since you have indicated that you made the application a single instance application, it is very likely that you are using VB's Application framework. This framework exposes the StartupNextInstance Event. From the documentation for that event.
You must use the CommandLine property of the e parameter to access the arguments for subsequent attempts to start a single-instance application.
To add a handler for that event, you can use the designer to create the handler via Project Menu->PropjectName Properties->Application Tab-View Application Events Button or just copy the following to a code file in your project.
Imports Microsoft.VisualBasic.ApplicationServices
Namespace My
Partial Friend Class MyApplication
Private Sub MyApplication_StartupNextInstance(sender As Object, e As StartupNextInstanceEventArgs) Handles Me.StartupNextInstance
' use e.CommandLine
End Sub
End Class
End Namespace

How PowerBuilder application act as host for another guest executable?

How i can run a 3rd party executable as child process in my PowerBuilder app?
The only objective i want to achieve is that the 3rd party exe file open and close just like we open and close a Sheet in PowerBuilder.
I dont want to give any other option to users of my app to close the 3rd party exe without closing my main PowerBuilder app. same way user is not allowed to run the 3rd party exe without running PowerBuilder app.
All that sound like some ActiveX behavior. So i can say if the 3rd party exe becomes an ActiveX then my objective is achieved. It is just my guess. really i can go for any other options that meets requirements.
If you have the window handle for the other app, you might be able to use the SetParent API function to attach it to a blank sheet window in the PowerBuilder app. The resize event of the sheet window would have to use the PB function Send to forward a resize event. The close event of the sheet window would then send the WM_CLOSE event.
There is a way you can open 3rd party exe like a response window within your PowerBuilder application. Though I am not sure if that will be useful to you as you want to open it like a sheet window. Anyway, the following is the code.
Local External Function Declration:
Function long FindWindowA (long classname, string windowname) LIBRARY "user32.dll" alias for "FindWindowA;Ansi"
Function Boolean BringWindowToTop (long classname) LIBRARY "user32.dll" alias for "BringWindowToTop;Ansi"
Local Function:
public function integer of_manage_third_party_exe ()
public function integer of_manage_third_party_exe ();///////////////////////////////////////////////////////////////////////////////////
//
// Returns 1 - window is not opened
// -1 : A window is opened so bring it to top
//
///////////////////////////////////////////////////////////////////////////////////
long ll_handle //unique id of window opened
ll_handle = FindWindowA(0,"Title of third party exe")
//If the window is not opened Then bring the window to top
If ll_handle > 0 Then
Post BringWindowToTop(ll_handle)
Return -1
End If
Return 1
Script in Activate event of your frame window/the window from which you are going to open the 3rd party exe:
of_manage_third_party_exe()
Script in CloseQuery event:
//if third party exe is open then don't allow to close the window
If of_manage_third_party_exe ( ) < 0 Then
Return 1
End If
I guess it will help you figure out rest of the places where you might have to use the of_manage_third_party_exe function based on your functionality.

VB6 - reading from keyboard in an ActiveX DLL

I have an ActiveX DLL which currently reads from a serial port. Now I want it to accept input from a USB device.
The USB device functions as a standard Human Interface Device. That is to say, if I open Notepad then the device's output will appear in Notepad as if it were typed on a keyboard.
Normally, I would capture Key Up/Down events, but I think that I need a form for that and my DLL does not have a form.
How can I capture that input?
[Update] I found this http://us.generation-nt.com/answer/anyone-know-how-read-keyboard-input-within-an-activex-dll-help-7934442.html# which claims to do it, but the code there won't work as is uses the AddressOf operator, which can only be used in a .BAS file, so not in an DLL .CLS
I am not even sure if I am looking for a system wide hook or application specific.
Hmmm, http://www.xtremevbtalk.com/showthread.php?t=77216 says "You can't implement a global WH_KEYBOARD hook in VB - it requires a standard (non ActiveX dll) as it has to be loaded into the address space of all the running applications."
[Upper date] So, maybe I can a form, make it 1x1 pixel and invisible and have a function GetTheData which shows the form modally and collects and returns the data - either getting keyboard input at form level or into a (n invisible) control then closes the form returning the input.
Would that work? If anyone posts a working example I will award a bounty (I would prefer that the form not be visible on the task bar and have no close button; the user should not be aware of it, or able to close it, it should close itself when it receives enough input from the USB attached HDI).
You can use RegisterRawInputDevices to monitor HID devices' input but this requires a window to listen for WM_INPUT message which means subclassing the window.
Here is a working sample project: UsbBarcodeSanner.zip
I think you have better option,
using uesr32.dll you can do this task easily,
refer this link
you will be able to use this function
Declare Function GetAsyncKeyState Lib "user32.dll" (ByVal vKey As Long) As Integer
This dll handles anything you want for user in windows.. refer Old Post
I hope this will help..

Threading in VB.Net Console Application

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.

Start VB.NET GUI app using Sub Main or form startup object?

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.).