Is it possible to adjust windows control panel settings from the command line? The settings I'm specifically interested in are the cursor width and blink rate, which can be customized in the Ease of Access Center [1]. I think this is a registry thing, right?
Same as Control Panel Settings from Command Line but I don't think a C# solution will work for me, because what I'm actually trying to do is toggle these cursor settings from AutoHotKey.
[1] https://bltt.org/adjusting-the-windows-text-cursors-blink-rate-and-width/
You can set the blink rate with the SetCaretBlinkTime function and the AHK code might look something like this:
DllCall("User32\SetCaretBlinkTime","Uint",666)
I'm not sure if you can change the width:
The width of the caret, in logical units. If this parameter is zero, the width is set to the system-defined window border width.
You can retrieve the width or height of the system's window border by using the GetSystemMetrics function, specifying the SM_CXBORDER and SM_CYBORDER values. Using the window border width or height guarantees that the caret will be visible on a high-resolution screen.
but on the other hand SystemParametersInfo has SPI_SETCARETWIDTH but it is only documented to work on edit controls.
Related
I needed to find out the height of the screen in order to resize a dialog. I am calling GetSystemMetrics with SM_CYFULLSCREEN and I am getting a certain number (1028 in my case). Per MSDN:
To get the coordinates of the portion of the screen not obscured by
the system taskbar or by application desktop toolbars, call the
SystemParametersInfo function with the SPI_GETWORKAREA value.
I called SystemParametersInfo as well to see what it returns and I get a different number for the height, 1050. Running spy, the area without taskbar is indeed of height 1050. Does anyone know why the different heights? Thanks
From the MSDN docs for SM_CYFULLSCREEN:
The height of the client area for a full-screen window on the primary display monitor, in pixels.
Relevant detail bolded, the client area is the part of the window without the borders and title bar. It is therefore substantially less than the actual primary screen height. Perhaps you meant to use SM_CYSCREEN instead. SPI_GETWORKAREA returns the available space for the entire window, the outer size, the one you'd pass to CreateWindowEx().
I'm looking to simulate a kiosk mode for Safari on Windows. OSX will not work with my input hardware and Chrome's GPU acceleration is too slow for the machine I'm using.
The only plausible solution [so far] is to run Safari and send an F11 (fullscreen) keystroke, but prevent the URL bar from expanding when the mouse reaches the top pixels of the screen.
I've looked and can't seem to find any good solution and would like to know if I can restrict the cursor movement from reaching the top pixel of the screen?
If anyone has any other solutions, that would be great!
You can use the ClipCursor function to do this.
Confines the cursor to a rectangular area on the screen. If a subsequent cursor position (set by the SetCursorPos function or the mouse) lies outside the rectangle, the system automatically adjusts the position to keep the cursor inside the rectangular area.
You can poll the cursor position and correct it using a timer, but this is not ideal. You could also cover the top bar by a transparent topmost window. This way, input will never reach the top bar.
EDIT: If Internet explorer is an option you have the possibility to use the COM object to embed what you need in a custom application. Other browsers might have similar APIs, but I'm not familiar with them.
I have a window with child windows inside in it. The child windows take up about 1000 pixels of vertical space. However, our users don't always have 1000 pixels of vertical space available - they might have as little as 500 or 600 pixels.
I want to be able to display this window at a size of 500 pixels high, and have the user "scroll" up and down the window to see the full contents. The window should always be 500 pixels high, but the view within it should change.
Assume I can add a scroll bar somewhere so the user can choose which part of the window he wants to see. Windows will normally paint the window contents from height 0 to height 500; how do I tell it instead to "paint from height 250 to height 750", for example?
I know that I can set the viewport with functions like SetViewportOrgEx etc, but those functions require a device context - when do I call them if I want them to be "permanent"? Do I call them when I get the WM_PAINT message from windows? Or at some other time? And which functions from that family do I want to use?
Edit to add: I don't want to actually change the position of the child windows - they should stay at the same position, and the only thing that should change is the view into the window.
Thanks.
If (when you get messages about the scroll bars changing) you call ScrollWindowEx with the SW_SCROLLCHILDREN flag, the child windows should be told to scroll along with everything else. This ought to put them in the right position.
I have this Win32 user-drawn tab control that is created as:
CONTROL "Tab1",IDC_TAB_CONT,"SysTabControl32",TCS_BOTTOM |
TCS_OWNERDRAWFIXED | NOT WS_VISIBLE,0,14,185,88
I'd like for this control to have its tabs resize as never to have to see the "sliding arrows":
Now, pretty much everything about this control works as expected, except for that fact that it won't respond to TabCtrl_SetItemSize. Try as I may, the size I get for the tabs when I get to draw them (in the DRAWITEMSTRUCT passed to WM_DRAWITEM) is always the size that fits the longest caption in them and never the size I've set with TabCtrl_SetItemSize.
However, in the TabCtrl_SetItemSize documentation, it says that:
[TabCtrl_SetItemSize] sets the width and height of tabs in a
fixed-width or owner-drawn tab
control.
The only way I've managed to have a decent resizing is by setting a dummy string of the desired length in it by sending the control a TCM_SETITEM message, and writing the desired text in it at draw time. This is rather inconvenient and not a particularly nice hack.
Is there anybody who would know
Why TabCtrl_SetItemSize isn't working as expected? and/or
How to set the tab size properly?
Many thanks,
joce.
Setting TCS_OWNERDRAWFIXED style is not enough, you have also to add TCS_FIXEDWIDTH style.
The minimum size of a tab is at least icon width + 3 if icon is present.
If you have icons (imageList attached to tabControl), you might get those "sliding arrows" even with fixed width (if there is less space available than: number of tabs*(icon width+3)
I am trying to create a full-screen control panel window with many controls: buttons, sliders, list boxes, etc.
I can create a dialog window and add controls to it, but everything is scaled in dialog units. I just want to create a window in the GUI editor that is scaled in pixels, not derived units like dialog units.
I can sort of lay out all the controls in the GUI editor and then resize the window programmatically to full-screen using SetWindowPos, but the dialog window in the GUI editor will not look the same as the final product. I want it to be WYSIWIG in the GUI editor.
This is the front end for a small dedicated instrument control computer running XP. The SDK is written in MFC. I have to add and change controls frequently. The screen is small, 7" # 800 x 600, so of course I am developing the program on a different computer. I don't want the program window to change when I change monitors -- I want it fixed at 800 x 600, and I want the controls to be fixed in size and layout as well.
There must be a way -- this is more basic than the default functionality.
Thanks.
Dialog Units are based on properties of the font used by the dialog. A horizontal dialog unit is equal to 1/4th the average width of the current font.
A vertical dialog unit is equal to 1/8th the average character height of the current font.
I'd recommend using method 2 (MapDialogRect() for a 4 x 8 dialog) to figure out how many DLUs 800x600 corresponds to on your output display then make a reference form equal to that size. You can later use that reference form while you're designing.
p.s.-I'm glad Visual Studio no longer emphasizes dialog units since they were always a pain to deal with.
Thanks. I was able to make a reference form by just resizing the form manually in the GUI editor over and over again until it exactly filled the screen... No kidding that dialog units are a pain. From your response, I guess in the current Visual Studio there is a better way to do this? (This is my first experience with Windows programming).