Explorer seems to always start my application with SW_MAXIMIZE (STARTF_USESHOWWINDOW is set in STARTUPINFO.dwFlags). I know that ShowWindow will use this value the first time you/Windows needs to display a window but it has the unfortunate consequence of maximizing a window that should never be maximized.
My window is created with CreateDialogIndirectParam and has the following styles: WS_CAPTION|WS_SYSMENU|WS_MINIMIZEBOX|WS_CLIPCHILDREN|DS_MODALFRAME|DS_CENTER|WS_VISIBLE. Why does ShowWindow not check if WS_MAXIMIZEBOX is set before allowing STARTF_USESHOWWINDOW to force SW_MAXIMIZE? Is this a bug in Windows?
This happens on a HP Stream 7 with Windows 8.1. I'm not sure if Explorer does this because it is touch enabled or because of the small screen.
Is this Explorer behavior documented anywhere and is there a way to turn it off? What is the best way to stop Explorer (or any other parent process) from affecting my initial window mode? (I don't want to block people starting me with SW_*MINIMIZE*)
WinVer.exe in system32 has the same problem:
My first thought was to turn off STARTF_USESHOWWINDOW in the PEB if the parent wanted me to start maximized but that is too nasty and undocumented so I have not tried that yet.
Preventing any kind of size change (which is OK for my application since it is just a "modal" dialog) sort of works:
case WM_WINDOWPOSCHANGING:
((WINDOWPOS*)lp)->flags |= SWP_NOSIZE;
return true;
The problem is that the window position is still set to 0 x 0 like a maximized window.
A better solution seems to be to detect and correct the problem after WM_INITDIALOG:
case WM_INITDIALOG:
PostMessage(hDlg, WM_APP, 0, 0);
break;
case WM_APP:
if (IsZoomed(hDlg)) ShowWindow(hDlg, SW_SHOWNOACTIVATE);
break;
I am the proud owner of several HP Stream 7 tablets and I would like to add my 2 cents here. Microsoft has made an arbitrary decision that devices with screen sizes smaller than 8 inches will behave differently than the norm. A lot of users are somewhat aware of this, but unaware that this is where your problem originates.
Windows determines a screen's size by reading the EDID information from the screen, which contains sizing information in it, in centimeters.
If no sizing information is present in the EDID, or the sizing information is below Microsoft's arbitrarily chosen 8 inch threshold, you get this apparent misbehavior which is at the very least, aggrivating to those who notice it and don't want it.
The solution is to override the default driver for the monitor in Device Manager with one that informs Windows that the screen is in fact, 8 inches or larger.
To do so, you need to first read the EDID information from the registry with a tool such as Deltacast's E-EDID Editor (free, last time I checked), and modify the size values and save the modified file someplace you can find it.
After you have modified your EDID file and saved it, download Monitor Asset Manager from EnTech (also free) and use it to create an INF file.
Once the INF file has been created, you need to restart Windows with the Advanced settings menu and choose to Disable Driver Signing Enforcement, since the INF file you created won't be digitally signed. Once disabled, open Device Manager in Windows and update the driver for the monitor using the INF file you created. You will need to confirm that you do in fact want to install the unsigned driver file.
Reboot and Windows will now behave normally with the one catch that, the onscreen keyboard will now appear a different size and will have more options available.
Sadly, Microsoft can change this behavior in the future, so there is no guarantee that through the same flawed decision making process they used to implement this in the first place, they won't force it down our throats again, using a much more difficult to counteract method.
I searched already for this for some time, but could not find a solution.
I have mouse_wheel_switches_tabs set to true, but on my system and with my mouse, when I scroll the minimal amount possible on the mousewheel, already 2 tabs are switched.
Is there a setting to make the amount, that the mousewheel advances (or goes back) in the open tabs smaller?
I do not want to change my mouse settings, because they are already adjusted to everything else.
I believe this should be adjustable, because you can never garanty that on all systems the mouse wheel has a similar pace.
I also tried to set the scroll_speed setting to values above or below 1, and also to 0, but this did not change anything.
I am on windows and I am not adding a version number, because I will happily switch to any version that can do this.
Mouse wheel is not something that is calculated in small steps, but rather it has a concrete amount of events fired for each scroll step, thus SublimeText can't do anything but receive 2 steps each time you do a scroll, this is controlled by system or your mouse, but I doubt that your mouse vendor has built a hardware that does fires two steps for this minimum amount.
So I highly doubt it's possible without changing your mouse settings. At least without tweaking the core of SublimeText, which is not possible as it's code is not open-source.
I have the following (minor) problem that I want to solve programmatically. Whenever I unplug my secondary monitor from my laptop, every windows get moved to be visible in the now smaller resolution. When I plug my external monitor back in, I need to manually replace the windows to their correct position. I have to do that every morning (sigh).
Now I decided to write a simple command-line program that could save the position of every open windows and reposition them when I want to restore their positions.
I have managed to do something that works just fine by using the Accessibility API, which allows me to control windows that aren't part of my process space. I have a problem though: the program can only see the windows that are in my current space (I'm talking about the OSX Spaces feature here).
In other words, when I run my program to save the windows positions, it will only be able to save the positions of the windows in the space I'm currently in.
Some more details about my program:
It loops through all the processes running and get their PIDs.
It creates application elements from these PIDs (AXUIElementCreateApplication)
It gets the windows associated with this application, and then their positions
When getting the windows elements from the application element, the AXUIElementCopyAttributeValues only returns me the windows of the current space.
Now, is there a way to control any windows (across different spaces)? If not, I wouldn't mind programmatically changing spaces to get every windows, but that doesn't seem possible.
Any help would be appreciated!
I'm not aware of a documented way to switch spaces.
You probably want CGSPrivate.h - CGSSetWorkspace et al. Just keep in mind those functions are SPI and can break without warning even in a 10.6.x release.
If you want to avoid using private APIs you can take advantage of the fact Mission Control has keyboard shortcuts for moving to various spaces, and you can programmatically send the key codes to activate them. I wrote a blog post about it (http://ianyh.com/blog/2013/06/05/accessibility/) for a tiling window manager I've been working on called Amethyst, which has some example code you can check out in -[AMWindow moveToSpace:].
The short version is moving to a space looks something like using the default ctrl + arrow key to move to adjacent spaces:
CGEventRef keyboardDownEvent = CGEventCreateKeyboardEvent(NULL, kVK_RightArrow, true);
CGEventRef keyboardUpEvent = CGEventCreateKeyboardEvent(NULL, kVK_RightArrow, false);
CGEventSetFlags(keyboardDownEvent, kCGEventFlagMaskControl);
CGEventSetFlags(keyboardUpEvent, 0);
CGEventPost(kCGHIDEventTap, keyboardDownEvent);
CGEventPost(kCGHIDEventTap, keyboardUpEvent);
CFRelease(keyboardEvent);
CFRelease(keyboardEventUp);
You could combine this with NSWorkspaceActiveSpaceDidChangeNotification to traverse all spaces and gather window data.
Also, as a potentially interesting note the accessibility APIs can actually give you windows across all spaces at the same time, but it will only give you windows in spaces that you have traversed to since the process utilizing the APIs launched. I have no idea why this is the case, but it does seem to be.
I can't understand the reasoning behind Most-Recent-Order (how Windows sorts windows when switching via Alt+Tab) when used for tab/window/document/task switching. The way Firefox does tab switching (tabs stay in a consistent order, Ctrl+Tab/Ctrl+Shift+Tab for moving to the next/previous tab) seems much more natural than switching in chronological order.
When there are more than ~5 tabs or windows, I quickly forget the chronological order in which they were opened. So the sequence of switching between them becomes difficult to predict. Even if I remember which tab was active before the current one, and which one was active prior to that, it just takes a lot of key strokes to switch to these. More than if I could simply use direct order as in Firefox or Chrome.
Is there any rational reason to use MRO in an application apart from backward compatibility (for users accustomed to the old hotkeys and usage patterns)?
Why is it still used in Windows for Alt+Tab switching between applications?
It's used because often you're switching between two applications so it's a simple Alt+Tab to switch back and forth. If it didn't use a most recently used order it could be mulitple keypresses to switch back and forth between the two apps I'm interested in at the moment.
Similarly, in an IDE, I could be switching back and forth between two files and don't want to hit Ctrl+Tab lots of times to keep making the same switch.
I appreciate it in Windows Alt-Tab switching, but hate it for situations where tabs are visually present at the top of the screen. When I can see the tabs, I want to switch between them in the order I can see them, since I can probably at a glance (and without any conscious effort) count the number of times I need to press tab; and generally I'm working with few enough tabs (I'm an avid hater of clutter) that this works for me.
In Windows, when the alt-tab dialog (if dialog is the appropriate term) doesn't persist, I want to use MRO for switching.
People usually work well with a few items at a time, and the attention span allows us to better concentrate onto a couple of recent pieces of information rather than onto lengthy lists. Think of it in terms of caching this recent information: if you've used something in the last couple of seconds, and switched away from it for a moment, it's likely that it will be the first thing that you'll want to use again when you switch.
I love stretching my terminal on unix. What is the history or reason behind windows lame command line?
It isn't. You can right click the title bar, select properties, and in the "Layout" tab alter the screen buffer size (line width and scrollback) and the window size (viewport size). If you started cmd from a shortcut, you can save these settings for future sessions.
If you are mouse-phobic you can also just type this inside the cmd window:
mode <cols>,<lines>
mode 80,25
mode 120,50
etc.
It's not limited.
Run cmd.exe
Click on the icon in the upper left hand of the screen.
Select Properties
Select the Layout tab.
Set the buffer and window widths to whatever you like.
Click OK
Select Save Properties for future...
Click OK.
You might want to check out Console. It's an open source app that lets you run multiple shells in a tabbed environment. You can also set the alpha-transparency of the shells.
RE: Because MS value "backwards compatibility" over a lot of things and in this case I suspect it's a misplaced belief that it will somehow unnerve people if they don't have their standard 80 wide window.
The backwards compatibility works pretty terribly, though. I don't imagine Microsoft was pretty thorough about their implementation of it, and I do believe Microsoft is the poster boy for making sure newer versions won't work on older versions. A lot doesn't work properly under COMMAND.COM, which considerably sabotages the usefulness it possesses, not to mention that you have to enter DOSONLY to make some programs run properly, plus Microsoft has been removing useful commands. Honestly, I can't imagine Microsoft holds "backwards compatibility" in much of a high regard.
Furthermore, I think the real reason why the line length is at a standard of 80 columns is because most command-line programs, etc. operate under the assumption that the user is capped at an 80 column prompt, meaning that increasing the width can cause formatting errors or worse possibly break programs altogether.
As jmucchiello mentioned, MODE will work fine for resizing the window if you feel like it.
Configures system devices.
Serial port: MODE COMm[:] [BAUD=b] [PARITY=p] [DATA=d] [STOP=s]
[to=on|off] [xon=on|off] [odsr=on|off]
[octs=on|off] [dtr=on|off|hs]
[rts=on|off|hs|tg] [idsr=on|off]
Device Status: MODE [device] [/STATUS]
Redirect printing: MODE LPTn[:]=COMm[:]
Select code page: MODE CON[:] CP SELECT=yyy
Code page status: MODE CON[:] CP [/STATUS]
Display mode: MODE CON[:] [COLS=c] [LINES=n]
Typematic rate: MODE CON[:] [RATE=r DELAY=d]
If you have DOSONLY enabled on your CONFIG.NT, however, when you open COMMAND.COM, it will inherit a proper DOS-style line resolution from cmd.exe, but you cannot invoke MODE from inside COMMAND.COM. If you wish to resize inside COMMAND.COM, you will have to use 16-bit assembly instructions, like so:
80x50 Line Resolution (No framebuffer, no SVGA, virtually universally supported.)
DEBUG
A100
MOV AX,1112
INT 10
INT 20
G
Q
132x60 Line Resolution (No framebuffer, requires SVGA. Won't work on ATI gfx cards, usually works on nVidia gfx cards, afaict always works on Intel integrated gfx cards.)
DEBUG
A100
MOV AX,4F02
MOV BX,010C
INT 10
INT 20
G
Q
If you enter this on your COMMAND.COM, it will give you the specified resolution. (Warning: If your monitor is ancient enough not to support the mode, you might wind up destroying it. Side-note: If you can run Windows, your monitor should be fine. Disclaimer: Emphasis on should, and you've been warned, so it's not my problem if your monitor fries. ;-) However, if you use this without DOSONLY enabled, COMMAND.COM will resize back to its previous size as soon as the application (in this case, unless you wrote it to a file and executed that, DEBUG) exits.
Alternatively, you could use FreeDOS's MODE.COM, which will run properly under COMMAND.COM set to DOSONLY. You can either pull it from the disk image at the official website (freedos.org) or get it at http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/mode/2005/.
New FreeDOS MODE by Eric Auer 2003-2005. License: GPL. (version 12may2005)
MODE [device] [/STA[TUS]] (show status of one or all devices)
MODE LPTn[:] cols[,[lines][,retry]] (cols or cpi, 6/8 lpi, retry p or n)
MODE LPTn[:] [COLS=...] [LINES=...] [RETRY=...] (retry: p infinite / n none)
MODE LPTn[:]=[COMn[:]|NUL] (redirect printer data to serial port or NUL)
MODE COMn[:] baud,parity,data,stop,retry (empty values allowed)
MODE COMn[:] [BAUD[HARD]=...] [PARITY=...] [DATA=...] [STOP=...] [RETRY=...]
Baud can be abbreviated to unique prefix, parity can be o/e/n/s/m, the
latter 2 mean space/mark, data can be 5..8, stop 1..2. Retry is IGNORED!
PLANNED: Retry b/e/r -> busy/error/ready if busy, p/n infinite/no retry.
MODE CON[:] [CP|CODEPAGE] [/STA[TUS]] (FreeDOS DISPLAY must be loaded)
MODE CON[:] [CP|CODEPAGE] REF[RESH] (needs DISPLAY)
MODE CON[:] [CP|CODEPAGE] SEL[ECT]=number (needs DISPLAY)
MODE CON[:] [CP|CODEPAGE] PREP[ARE]=((codepage) filename) (needs DISPLAY)
Use PREP=((,cp2,cp3,,cp5) ...) to prep codepages in other buffers.
MODE [40|80|BW40|BW80|CO40|CO80|MONO][,rows] (rows can be 25, 28, 43 or 50)
Use 8, 14 or 16 as 'rows' value if you only want to change the font.
MODE [CO40|CO80|...],[R|L][,T] (shift CGA left/right, T is interactive mode)
MODE CON[:] [NUMLOCK|CAPSLOCK|SCROLLLOCK|SWITCHAR]=value
Value can be: + or - for the locks or a character for switchar.
MODE CON[:] [COLS=...] [LINES=...] (possible values depend on your hardware)
MODE CON[:] [RATE=...] [DELAY=...] (default rate 20, default delay 1)
Rate can be 1..32 for 2..30 char/sec, delay can be 1..4 for 1/4..4/4 sec.
For the same reasons as with the ASM code I provided, unless you execute it in COMMAND.COM with DOSONLY added to your CONFIG.NT file, the window will immediately rebound to its previous size once MODE.COM exits.
Lastly, as others have stated, it is also possible to modify these settings simply by right clicking on the command prompt's title bar, and modifying Properties -> Layout. Similarly, you can set the resolution for any shortcuts to CMD.EXE and batch files (Right click the shortcut -> Properties -> Layout). This only works for CMD.EXE, however, not COMMAND.COM.
A simple command to fix the window size that I use all the time:
wmic
It will open the Windows Management Instrumentation Command-line and remove the size limits.
Then just close it with Ctrl+C.
I don't know the history behind it, but this wishlist item from the author of PuTTy is an interesting post that explains the technical hurdles involved with any type of cmd.exe replacement that isn't lame:
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/win-command-prompt.html
You don't mention that you're looking for a replacement, but if so you might also check out some of the cmd.exe replacements like Console 2 or JP Software's Take Command etc. I've also had some good experiences with PuTTy-Cyg which lets you use PuTTy as a cygwin shell.
While the width is not limited as other answers show, I've always found it strange that one can drag and resize the height with the mouse, but not the width.
I think the default 80 character width is related to compatibility with old programs that assume the terminal won't be more than 80 characters wide. I don't think this has been a realistic reason for a decade or so, though.
As others have pointed out, it's not limited to 80 characters wide, but my guess as to why it defaults to 80 characters would be that it's left over from the DOS days where CRT displays were 80 characters wide.
See also
You could also use a different terminal application, such as Console2, which allows you to resize the window all you want (among other things, such as transparency, and the ability to use any font you'd like). It's a great application, I've switched to it and now I only use cmd.exe when I absolutely have to.
Since it will scroll left to right as well as up and down, the very first thing I do on a system is define my width as 180 and save it. That's generally enough so that stack traces don't have to wrap for the most part, but not so much that you are waisting a ton of space.
While you're at it, set the vertical size (scrollback buffer) to all 9's. You'll be glad you did some day.
Because MS value "backwards compatibility" over a lot of things and in this case I suspect it's a misplaced belief that it will somehow unnerve people if they don't have their standard 80 wide window.
Of course it could be that it was programmed for a fixed 80 chars width when that was pretty much universal, and the additional property settings were a bit of a hack.
It IS limited. Check it out. (I mean window size NOT buffer)
You will find that the maximum width you can set is limited but varies according to your screen resolution. If your resolution is set to 1024 x 768 you will find that you can only get to 128 on the command prompt width. 128/1024=.125
you will find that ratio to be consistent across the board. I have an RDP session running at 2000x768 (across two of my three monitors) and get a max width of 250.
Now, that actaully turns out to be a little bigger than your actaul monitor size but I have three monitors all running individual desktops. (so in essence, 3 1024x768 resolutions) and if I want to do something SO SIMPLE as stretch a command prompt across 2 or more monitors, I CAN'T. (I want to when doing things with very long paths (diruse.exe/etc.)...
-c
This isn't closed. So it should be noted that Windows Terminal is now is changing all of this:
https://github.com/microsoft/terminal
https://www.theverge.com/2020/1/9/21059316/microsoft-windows-terminal-crt-effects-retro-search-tabs-features
https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/
https://github.com/microsoft/terminal/blob/master/doc/terminal-v1-roadmap.md
https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701?activetab=pivot:overviewtab
Because improving the usability and functionality of anything that Unix/GNU-like development requires will undermine Windows as a commercial platform for Microsoft's partners. Preventing this means other large companies' products for developers, such as improved terminals, and other general third party products, like word processors, video players etc. aren't competing with existing Unix/GNU software. Without this, Windows wouldn't be a profitable platform, and Microsoft would lose its desktop monopoly.
This is why the terminal sucks, there's no POSIX API, no C99 support in MSVC and the list goes on. To clarify, common Unix/GNU technologies and development are intentionally unsupported so that large commercial software houses don't have to compete with them.