Someone may have already posted about this, but I am working on an application in VB.NET that requires me to switch to another open window and maximize it. I cannot for my life figure out a reliable way to do this (I gave up and called an autohotkey script, but even that broke). Any help is greatly appreciated!
Edit: I saw the forum post here, but it doesn't seem to work
If you take a look at the post you already mentioned, you will notice that it contains following line:
Dim localByName As Process() = Process.GetProcessesByName("met2")
You need to replace "met2" string with exact name of process whose window you're trying to maximize. If you don't know the name of targeted process, do the following:
run the application you intend to maximize
open Task Manager
switch to "Processes" tab for complete list of running processes
pinpoint the process you're looking for (commonly the filename of running application)
use process name (commonly filename of the application) without extension as a friendly process name
For example, if you want to maximize running Notepad application using methodology explanied in this post you will need to change following in existing code:
Dim localByName As Process() = Process.GetProcessesByName("notepad")
Related
I'm trying to (in my menu-strip) open the update log from my program. I have an .msi for it, but the problem is that I don't know where the user will install the program. For example, in my code I could put the path of C:\Program Files\Colour Picker\updatelog.txt. But what if the user installed the program elsewhere? They would try to open the update log text file and be presented with an error.
Possibly there is a way to open the text file from the install location. So in pseudocode,
OPEN updatelog.txt(InstallLocation).
One way to get where the application is stored is by using My.Application.Info.DirectoryPath.
Here's the documentation
Using this in combination with a TextReader or StreamReader should work well enough for you.
Without knowing your specific implementation, I can't offer a specific answer. If you update your question, I'll refine my answer. For now, I believe this may be enough.
Log files are best kept in a location different from the application installation folder. You won't want to get tripped up by administrative access requirements.
For example, as a best practice you could use something like this:
Dim sLogFile As String = "UpdateLog.txt"
Dim sAppData As String = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
Dim sAppName As String = "Colour Picker"
Dim sLogPath As String = IO.Path.Combine(sAppData, sAppName, sLogFile)
If you want to make the log file user-accessible, you can provide a means to open it in your UI and point to that location.
I'm VERY new at VB .NET and have recently downloaded MS Visual Studio Express 2012. I'm trying to design an application to replace a VBScript I created and can't find the answer to Two of the main design phase features I require so I apologize ahead of time for my ignorance.
I'm trying to create an application to edit the configuration parameters of an existing application I support. the configurations are edited in both the Files System and in the Windows Registry.
I'm looking for a way to pass a "/q" or "/quiet" and allow the application to run silently. I have developed the program far enough to edit the options in the form and save them. I can run code (so far only messages displaying the options) from the start configuration button from a "Windows Form Application".
I'm also needing to make sure that when running silently the application does not need UAC elevation. In the original VBScript I need to elevate UAC when editing the Windows Registry.
I know this is a lot to ask for with my current knowledge level. But I'm still in the design stage and trying to learn fast and really need to know if this is even possible before I go too far.
If the original application required UAC elevation to edit the registry then the new one will too. The level of access is on a per user basis not a per application basis so unless you run the application as a different user you will have the same problem with your new application.
As to running without showing the form you will need to edit Main something like this:
<STAThread()> _
Shared Sub Main()
' Read the arguments
' Starts the application.
if (argument == "/q" or argument == "/quiet") then
' Edit the other program configurations here
else
Application.Run(New Form1())
End if
End Sub
You can call a version of Run(ApplicationContext ) that doesn't show a form, but as the starts the message loop you'd still need some way of actually editing the other program's configuration, perhaps in response to key strokes.
I have a small VB .Net application that, among other things, attempts to substitute system wide typed text by the user(hotstrings concept). To achieve that, I have deployed 'ahk2exe' and 'AutoHotkeySC.bin' with my application and did the following:
When a user assignes a new 'hotstring':
Kill 'hotstring' exe script file if running
Append new hotstring to the script file (if non exist then create a new one)
Convert edited/new script file to exe (using ahk2exe)
Run the newly converted script exe
(somewhere there I also check if the hotstring has been already assigned)
However, I am not totally satisfied with this method for the following two main reasons:
The extra resources deployed with the application.
Lag: The time it takes for the system to kill the process and then restart it takes a minimum of 5 seconds on my fast computer and more on other computers. That amount of time is much more than the time it takes the user to assign the hotstring, minimize/close the window and then test his/her new hotstring. When the user does so initially with no success they will think the process failed. So this method is not very good for user experience.
So, I am looking for a different method or implementation. May be using keyboard hooks? Or maybe adding a .dll library that achieves the same. Are there any resources you know about that might help (free or commercial)? What is the best way to achieve my desired goal?
Many thanks for your help.
Implementing what Autohotkey does would be a pretty non trivial task.
But I'm pretty sure that AHK supports an "autoreload" option for scripts
googling "autohotkey auto reload" turned up several pages discussing that very concept. IF that worked, all you'd have to do is update the script file and that's it, AHK should automatically reload the script.
I'm writing a macro to automate the process of attaching to the IIS worker process (w3wp.exe, Windows Server 2k8) from Visual Studio. The trouble is that I often two app pools running at any given time, one in x64 mode and one in x86 mode. This means there are two processes called w3wp.exe running at any given time, and the only way to distinguish between them is the mode they are running in. When I use the "Attach to Process" dialog, there is a "Type" column that shows that information so I know which w3wp.exe to attach to, but I can't figure out how to get that information in my macro.
Based on information here, I was able to come up with the following:
Function AttachToProcess(ByVal processName As String) As Boolean
Dim proc As EnvDTE.Process
Dim attached As Boolean
For Each proc In DTE.Debugger.LocalProcesses
If proc.Name = "w3wp.exe" Then
proc.Attach()
attached = True
End If
Next
Return attached
End Function
But half the time this just grabs the wrong process. I need a second if statement to check the mode/type of the process. I've spelunked through the classes using quickwatch as best I can, but just cannot figure out where the information is. Can anyone help? Thanks!
There's not enough info in the Process class to let you find out. You can only get the ProcessID for the process. From there, you'd have to P/Invoke OpenProcess() to get the process handle, then IsWow64Process() to find out if it is a 32-bit process. CloseHandle() to close the process handle. Not actually sure if P/Invoke is possible in a macro. Visit pinvoke.net to get the declarations you'll need.
My question is similar to Running a CMD or BAT in silent mode, but with one additional constraint.
If you use WshScript.Run in vbscript, you lose access to the standard in/error/out streams of the process. WshScript.Exec gives you access to the standard streams, but you can't hide your windows. How can you have your cake (hide the windows) and eat it too (have direct access to the console streams)?
I'm currently thinking about a C++ executable which creates a new Windows Station and Desktop, (see MSDN) and runs a specified script within that new Desktop (I'm not yet an expert on Window Stations and Desktops, so this idea may be retarded).
This idea is based loosely on Condor's USE_VISIBLE_DESKTOP feature, which, if disabled, runs Condor jobs in a non-visible Desktop. I haven't quite figured out if this requires elevated priveledge.
The tradeoff of this approach is that your script can disappear into limbo if it blocks on user input.
Does anyone have any additional ideas? Or feedback on the approach outlined above?
Edit:
Also, the purpose of our script is to set up the user environment, so running as another user, or as a system scheduled task isn't really an option (unless there are clever tricks I don't know about).
I didn't have any luck with the VBScript fragment above - the windows would still pop up. However I did find a tool called hstart, which looks like about what I need. Unfortunately it isn't open source, or free for commercial use.
Cygwin (http://www.cygwin.com/) comes with a utility named run.exe which does what you are asking for a generic process. You could use this to wrap your call to cscript. Cygwin is GNU so free for commercial or personal use.
I only tested this a little bit, so YMMV...
Put the following code into a .vbs file (I called mine HideWindow.vbs):
Const HIDDEN_WINDOW = 12
computer = "."
Set oWmiService = GetObject("winmgmts:" & _
"{impersonationLevel=impersonate}!\\" & _
computer & "\root\cimv2")
Set oStartup = oWmiService.Get("Win32_ProcessStartup")
Set oConfig = oStartup.SpawnInstance_
oConfig.ShowWindow = HIDDEN_WINDOW
Set oProcess = GetObject("winmgmts:root\cimv2:Win32_Process")
ret = oProcess.Create("cmd.exe /c C:\Scripts\test.cmd", null, oConfig, pid)
Call it from a batch file or command line like this:
CSCRIPT HideWindow.vbs
Whatever you put in test.cmd will run without displaying a window. This could be improved in several ways, but especially by parameterizing the program that gets called by oProcess.Create.
You could use Exec, a freeware tool I wrote that provides a command-line interface for the CreateProcess Windows API call. The GUI version doesn't have a console itself, and you can use it to start a shell script (batch file) in a hidden window.
Bill