In windows I can maximize current window by keyboard shortcut Alt+space then x. When I working on command prompt, can I do same thing using commands (without using shortcuts)?
Simply I need to create a bat file , that make windows maximize after run that.
Edit:
I need to do this without restarting the command prompt. because restart lost the content of existing window.
I've not found any reliable way of doing it without a third party tool. So, if you have access to a c compiler, you can build your own
#define _WIN32_WINNT 0x0500
#include "windows.h"
int main(int argc, char **argv){
ShowWindow(
(HWND) GetConsoleWindow(),
argc > 1 ? atoi( argv[1] ) : SW_SHOWDEFAULT
);
return 0;
}
Tested with mingw/gcc. This code uses the ShowWindow api function to change the show state of the current console window (handle retrieved via GetConsoleWindow()). If compiled to showWindow.exe you can do
showWindow.exe 3 to maximize the window
showWindow.exe 6 to minimize the window
showWindow.exe to return to default mode
See the api documentation for the full list of allowed values.
i think you'll have to check for additional software like autoit or
CMDOW
Related
In most applications, when you click some MenuItem, a WindowsMessage is sent (usually WM_COMMAND), with a wParam representing the ID of the chosen MenuItem.
There is a certain program that has a Window Menu (the menu accessible via clicking the program's icon on the title-bar),
and I want to find what is the WindowsMessage that is sent when I choose a specific MenuItem from that Menu.
The program is soething you all know - the Command Prompt window, in Windows XP:
(cmd.exe)
And here is the Window Menu:
I want to capture the WindowsMessage and wParam for a MenuItem there,
for example the "Paste" MenuItem.
(but not just it.. any other might be as well)
Here is what I tried:
Method 1:
The first method I always try is to use Spy++.
The problem is that when I try to Log Messages for this specific program (the DOS window), Spy++ gives me this messagebox:
For some reason Spy++ won't capture WindowsMessages for this program.
So I went on to the second method that I use..
Method 2:
Resource Hacker (ResHacker.exe) is also good for finding the WindowsMessage that is sent from clicked MenuItems, and it does it quite easily.
If you run Resource Hacker, and then Open some EXE file with it,
you usually see these trees, which one of them is called "Menu",
and it contains all the details including the wParam:
The problem is, that when I try to use Resource Hacker on cmd.exe,
I get this:
As it can be seen, no "Menu" tree there.
My question:
Are there other ways, in addition to the 2 methods that I usually use,
that can be used to find the WindowsMessage (and wParam) that is sent for the "Paste" MenuItem in the Window Menu of the DOS window?
0xfff1 is the wParam, so in C# (you didn't specify the language you were using, but it should be easy enough to translate it):
[DllImport("User32.dll")]
public static extern int SendMessage(IntPtr hWnd, int uMsg, int wParam, uint lParam);
public const int WM_KEYDOWN = 0x01000;
void PasteInCommandPrompt(IntPtr hWnd)
{
SendMessage(handle, WM_COMMAND, 0xfff1, 0);
}
http://blogs.msdn.com/b/bill/archive/2012/06/09/programmatically-paste-clipboard-text-to-a-cmd-window-c-or-c.aspx
Edit: 22 September 2019
In the comments of Console window - programmatic command code (wParam of WM_COMMAND) (a question where a user was using the above link to Bill Lin's blog, but having trouble getting it working), #eryksun gave me the idea of looking for a ConvhostV2.dll.mui to find the all available menu commands. I couldn't find ConvhostV2.dll.mui...
But on my system I found C:\Windows\System32\en-US\ConhostV1.dll.mui, which when viewed with Resource Hacker (as #spaceman tried with cmd.exe), contains all the menu items available for cmd.exe.
The complete list of commands cmd.exe has are:
0xfff0: Copy
0xfff1: Paste
0xfff2: Mark
0xfff3: Scroll
0xfff4: Find
0xfff5: Select all
Besides paste (which allows you to execute arbitrary commands), select all and copy are very useful, as they let you get console output (albeit, stripping all virtual terminal sequences, the characters that specify text color).
If you are going deep into the route of manipulating command windows you may also be interested in the new "Windows Pseudo Console", which can let you have full control over cmd.exe, or any command line based application. See https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ .
I am currently switching input sources by running a GUI AppleScript through Alfred, and the GUI script can sometime take up to 1s to complete the change. It gets quite annoying at times.
I have come across Determine OS X keyboard layout (“input source”) in the terminal/a script. And I want to know since we can find out the current input source if there's a way to change input source programatically? I'd tried overwriting the com.apple.HIToolbox.plist but it does not change the input.
(I do realise there's mapping shortcut to input sources available in the system preference, however I prefer mapping keywords with Alfred)
You can do it using the Text Input Services API:
NSArray* sources = CFBridgingRelease(TISCreateInputSourceList((__bridge CFDictionaryRef)#{ (__bridge NSString*)kTISPropertyInputSourceID : #"com.apple.keylayout.French" }, FALSE));
TISInputSourceRef source = (__bridge TISInputSourceRef)sources[0];
OSStatus status = TISSelectInputSource(source);
if (status != noErr)
/* handle error */;
The dictionary in the first line can use other properties for other criteria for picking an input source.
There's also NSTextInputContext. It has a selectedKeyboardInputSource which can be set to an input source ID to select a different input source. The issue there is that you need an instance of NSTextInputContext to work with and one of those exists only when you have a key window with a text view as its first responder.
#Ken Thomases' solution is probably the most robust - but it requires creation of a command-line utility.
A non-GUI-scripting shell scripting / AppleScripting solution is unfortunately not an option: while it is possible to update the *.plist file that reflects the currently selected input source (keyboard layout) - ~/Library/Preferences/com.apple.HIToolbox.plist - the system will ignore the change.
However, the following GUI-scripting solution (based on this), while still involving visible action, is robust and reasonably fast on my machine (around 0.2 seconds):
(If you just wanted to cycle through installed layouts, using a keyboard shortcut defined in System Preferences is probably your best bet; the advantage of this solution is that you can target a specific layout.)
Note the prerequisites mentioned in the comments.
# Example call
my switchToInputSource("Spanish")
# Switches to the specified input source (keyboard layout) using GUI scripting.
# Prerequisites:
# - The application running this script must be granted assisistive access.
# - Showing the Input menu in the menu bar must be turned on
# (System Preferences > Keyboard > Input Sources > Show Input menu in menu bar).
# Parameters:
# name ... input source name, as displayed when you open the Input menu from
# the menu bar; e.g.: "U.S."
# Example:
# my switchToInputSource("Spanish")
on switchToInputSource(name)
tell application "System Events" to tell process "SystemUIServer"
tell (menu bar item 1 of menu bar 1 whose description is "text input")
# !! Sadly, we must *visibly* select (open) the text-input menu-bar extra in order to
# !! populate its menu with the available input sources.
select
tell menu 1
# !! Curiously, using just `name` instead of `(get name)` didn't work: 'Access not allowed'.
click (first menu item whose title = (get name))
end tell
end tell
end tell
end switchToInputSource
Solution using Xcode Command Line Tools
For those, who would like to build #Ken Thomases' solution but without installing Xcode (which is several GiB and is totally useless to spend so much space on unless used seriously) it is possible to build it using the Xcode Command Line Tools.
There are several tutorials on the internet about how to install Xcode Command Line Tools. The point here is only that it takes fraction of the space compared to full-blown Xcode.
Once you have it installed, these are the steps:
Create a file called whatever.m
In whatever.m put the following:
#include <Carbon/Carbon.h>
int main (int argc, const char * argv[]) {
NSArray* sources = CFBridgingRelease(TISCreateInputSourceList((__bridge CFDictionaryRef)#{ (__bridge NSString*)kTISPropertyInputSourceID : #"com.apple.keylayout.French" }, FALSE));
TISInputSourceRef source = (__bridge TISInputSourceRef)sources[0];
OSStatus status = TISSelectInputSource(source);
if (status != noErr)
return -1;
return 0;
}
Replace French with your desired layout.
Save the file
Open terminal in the same folder as whatever.m is
Run this command:
clang -framework Carbon whatever.m -o whatever
Your application is created as whatever in the same folder and can be executed as:
.\whatever
Additionally
I've never created any Objective-C programs, so this may be suboptimal, but I wanted an executable that can take the keyboard layout as a command line parameter. For anyone interested, here's the solution I came up with:
In step 2 use this code:
#import <Foundation/Foundation.h>
#include <Carbon/Carbon.h>
int main (int argc, const char * argv[]) {
NSArray *arguments = [[NSProcessInfo processInfo] arguments];
NSArray* sources = CFBridgingRelease(TISCreateInputSourceList((__bridge CFDictionaryRef)#{ (__bridge NSString*)kTISPropertyInputSourceID : [#"com.apple.keylayout." stringByAppendingString:arguments[1]] }, FALSE));
TISInputSourceRef source = (__bridge TISInputSourceRef)sources[0];
OSStatus status = TISSelectInputSource(source);
if (status != noErr)
return -1;
return 0;
}
In step 6. run this command:
clang -framework Carbon -framework Foundation whatever.m -o whatever
You can now switch to any layout from the command line, e.g.:
./whatever British
Note: it only allows to switch to layouts already configured on your system!
Another option is to use Swift. It can be used in a script-like fashion (no compilation).
Install Xcode Command Line Tools
Create a script from the code below
Run the script using swift script_file_name
Code:
import Carbon
let command = ProcessInfo.processInfo.arguments.dropFirst().last ?? ""
let filter = command == "list" ? nil : [kTISPropertyInputSourceID: command]
guard let cfSources = TISCreateInputSourceList(filter as CFDictionary?, false),
let sources = cfSources.takeRetainedValue() as? [TISInputSource] else {
print("Use \"list\" as an argument to list all enabled input sources.")
exit(-1)
}
if filter == nil { // Print all sources
print("Change input source by passing one of these names as an argument:")
sources.forEach {
let cfID = TISGetInputSourceProperty($0, kTISPropertyInputSourceID)!
print(Unmanaged<CFString>.fromOpaque(cfID).takeUnretainedValue() as String)
}
} else if let firstSource = sources.first { // Select this source
exit(TISSelectInputSource(firstSource))
}
This elaborates on answers by Ken Thomases and sbnc.eu.
On AppleScript you must only take cmd + "space" (or something other, what you use for change keyboard source).
And all what you need:
key code 49 using command down
49 - code of 'space' button in ASCII for AppleScript.
P.S.: don't forget get access for you AppleScript utility in System Preferences.
tell application "System Events"
key code 49 using control down
end tell
Changes layout via keypress
I'm creating a system that uses multiple cursors (pointers) in multiple xsessions. My computer has multiple video cards in it for controlling different monitors. I want to have a different cursor on each screen and control each. Each monitor is a different session.
I started using the xlib library in C to control the single cursor I have using the following command:
XWarpPointer(display,None,window,0,0,0,0,x,y);
This works perfectly for one cursor. Then I created a second cursor using xinput in the terminal:
>>xinput create-master second
and then I have two cursors on screen. I can go and control each with a separate mouse by using the reattach command:
>>xinput reattach MOUSEID POINTERID
The last step is to control each cursor separately using xlib. When I use the xWarpPointer command it just moves the original cursor around and I can't find a way to designate which cursor to control. I have also been unable to find a way to set the default pointer. You can see a list of all the pointers using "xinput list" in terminal. Does anyone know how I can
Thanks for the help!
You need to use XIWarpPointer request from XInput2 extension, it takes deviceid as parameter
Bool XIWarpPointer(
Display* display,
int deviceid,
Window src_win,
Window dst_win,
double src_x,
double src_y,
unsigned int src_width,
unsigned int src_height,
double dst_x,
double dst_y
);
We have a need in one of our apps where we need to disable some of the built in gestures for Windows 8 to prevent users from leaving the app. (think kiosk sign in screen). Are there methods for still allowing the user to interact with the app using touch but disabling/intercepting some of the built in gestures (things like docking the app on the left, going to the desktop, etc).
Our backup solution is to disable touch altogether when in certain screens (this is something we can do) but we'd like a better user experience and to just disable the gestures that we absolutely need to (similar to disabling the windows key, ctrl+alt+del instead of the whole keyboard).
Initial searches and investigation haven't turned up what we've been looking for so we're either looking for the wrong thing or in the wrong places.
You can disable gesture in Windows 8 Embedded. Maybe you can try this in Windows 8.
Registry Keys:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ImmersiveShell\EdgeUI]
"DisabledEdges"=dword:0000000f
0x01 : Disables left edge input and app switcher gesture.
0x02 : Disables right edge input and charm bar gesture.
0x04 : Disables top edge input and top application bar gesture.
0x08 : Disables bottom edge input and bottom application bar gesture.
if you want to disables each gesture, just add dword:0000000f (15)
To do it programmatically, you can call the function in the link below. It requires the hWnd to the window you would like to target.
http://msdn.microsoft.com/en-us/library/windows/desktop/jj553591%28v=vs.85%29.aspx
The C++ below will search for a window with the window title "helloworld", and disable all of the Windows 8 gestures for it. This does not work for Windows Store apps, and the function has to be called on the window while it is open. If the application is closed and re-opened, the gestures will return. Also, I believe it only works while the application is full-screen.
#include "stdafx.h"
#include <windows.h>
#include <iostream>
#include <propsys.h>
#include <propkey.h>
using namespace std;
HWND windowHandle;
HRESULT SetTouchDisableProperty(HWND hwnd, BOOL fDisableTouch)
{
IPropertyStore* pPropStore;
HRESULT hrReturnValue = SHGetPropertyStoreForWindow(hwnd, IID_PPV_ARGS(&pPropStore));
if (SUCCEEDED(hrReturnValue))
{
PROPVARIANT var;
var.vt = VT_BOOL;
var.boolVal = fDisableTouch ? VARIANT_TRUE : VARIANT_FALSE;
hrReturnValue = pPropStore->SetValue(PKEY_EdgeGesture_DisableTouchWhenFullscreen, var);
pPropStore->Release();
}
return hrReturnValue;
}
BOOL CALLBACK MyEnumProc(HWND hWnd, LPARAM lParam)
{
TCHAR title[500];
ZeroMemory(title, sizeof(title));
GetWindowText(hWnd, title, sizeof(title)/sizeof(title[0]));
if (!_tcscmp(title, _T("helloworld")))
{
SetTouchDisableProperty(hWnd,true);
}
return TRUE;
}
int _tmain(int argc, _TCHAR* argv[])
{
EnumWindows(MyEnumProc, 0);
return 0;
}
Windows charms bar is operated by explorer.exe.
So if your app can run without it then you can hack around it by first disabling the autorestart of explorer.exe via (run as administrator):
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "AutoRestartShell" /t REG_DWORD /d 0
Then the lines below represent my launch.bat - which works in the end as expected:
;; kill explorer (this disables all windows functionalities
taskkill /f /im explorer.exe
;; start your kiosk app - should block the batch execution (so explorer.exe doesn't get executed at the end)
"\path\to\your\app.exe"
;; relaunch explorer.exe after you close the app to give back the functionality to windows
explorer.exe
I use the approach outlined above to let a keyboardless kiosk app run. Because with a keyboard you can still close the app with alt+f4.
Setting IsTapEnabled, IsDoubleTapEnabled, IsRightTapEnabled, and IsHoldingEnabled to false should disable the gestures in the UI Element but they are properties, not methods. I haven't seen a method that will disable ALL gestures for a particular element.
I know it would be ridiculous to disable each control to respond to the gestures but if you need to disable all controls literally from Root to Children then creating an attach property on the root and setting these properties to false might be a solution.
The gestures are handled by explorer.exe.
If your replace the windows shell (default: explorer.exe) with your Application, then there are no more gestures at the OS-level.
Registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows_NT\CurrentVersion\Winlogon\
Key: "Shell" (REG_SZ) = "path_to_your_application"
you can also do this only for the current user (HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows_NT\CurrentVersion\Winlogon)
At least in 8.1, there appears to be a feature called Assigned Access:
http://blogs.technet.com/b/askpfeplat/archive/2013/10/28/how-to-setup-assigned-access-in-windows-8-1-kiosk-mode.aspx
http://windows.microsoft.com/en-us/windows-8/assigned-access
Settings > Change PC Settings > Accounts > Other Accounts > Set up an account for assigned access
So i'm kinda into MS-DOS and such again, but i came to ask myself, How can i minimize a DOS window?
Any kind would be ok, minimalize, shrink to a tiny blue block.
I just can't seem to find a way to let it work on my Windows XP computer, is realy evrything excluded in XP?!
You can start a program in a new minimised window using the start command:
start /min your_command_here
One thing you could do is create a windows program that will find the title of the cmd window you are running in and in that program minimize it. In Win32 you would use the FindWindow command to get a window handle, then CloseWindow to minimize it. Something like this totally untested program:
int main(int argc, char** argv)
{
HWND wnd = FindWindow(
NULL,
argv[1]
);
CloseWindow(wnd);
return 0;
}
Within the cmd window you could set the title to some string that you define (to avoid ambiguities) and then pass that name to the program to your program:
C:\>title TitleOfWindowToMiniMize
C:\>minimizeWindow TitleOfWindowToMiniMize
You can't. Not in DOS. DOS has no concepts of windows.
In Windows you could write a little program that will look up your window and send it the appropriate message causing it to minimize. The same way you could also maximize or hide/show your window.