I have a basic Win32 dialog-based application. How do I make it resize?
If it was a window this would be possible by default (and it would fire WM_SIZE). I'm new to dialogs and I'm not able to figure out how to: 1. when mouse cursor hovers over the edge, it should change to IDC_SIZEWE or IDC_SIZENS, 2. just resize the dialog, I know how to position dialog's content.
You don't need to do the work yourself about moving the cursor to the edge, there is just a style you need to set in the .rc file or the dialog editor.
From the dialog editor: Set the border to Resizing to allow resizing of the dialog box.
From editing the .rc file directly: Append | WS_THICKFRAME to the line with STYLE
What window styles have you set on your dialog?
If you're using a framework such as MFC, you can repair a dialog that is no longer resizable by making sure the WS_THICKFRAME / WS_SIZEBOX or other suitable window style is set. In some development environments, this may also be set in the properties for the dialog if you are using something with runtime support.
If you created the window manually, specify one or the other in your call to CreateWindow / CreateWindowEx along with your other window styles. Some window styles, such as WS_OVERLAPPED also imply a resizable frame.
Window Styles # MSDN
CreateWindowEx # MSDN
Note - I tried doing this by calling ModifyStyle() on the window in the onInit(). However it does not work. You get the resize cursor, but no sizing happens.
This apparently has to be set in the RC file or maybe eralier in the window creation.
Related
Sometimes in the Windows OS, a program is able to open a new window which disables it's underlying window. Closing the newly opened window of course re-enables the first window. I want to enable the underlying window without closing the newly opened window with Autohotkey.
I made a gif which shows the situation perfectly:
https://imgur.com/a/EWt8OrF
I thought I might be able to pull this off with window styles and window extended styles, so here's what I tried:
^!e::
MouseGetPos,,, WindowUnderMouse
WinSet, Style, -0x8000000, ahk_id WindowUnderMouse
return
But it didn't work. I also did a lot of googling on this, but I didn't know what would be the proper keywords so I didn't find anything. Any idea how to accomplish this?
Some keywords for google:
How to make a modal window modeless
How to enable a disabled window
How to make a palette window
How to make a modal window a palette window
How to enable parent window
Child window disabling parent window
https://autohotkey.com/board/topic/49376-making-a-gui-dialog-modal/
https://autohotkey.com/docs/commands/Gui.htm
I have created a Scintilla window using CreateWindow() and want to set the title dynamically as different files are loaded into it. However, SetWindowText() is setting the content of the edit box rather than the caption. I also tried WM_SETTEXT to the same effect.
How do I set the title of the window instead?
Is the Scintilla window a top-level window with a caption? That is usually not the correct way to do things, you should create a custom container window with a caption and the Scintilla window should be a child window. This child window can take up the entire client area if required.
Using a control directly as a top-level window is not just problematic because of the caption text issue, there are also often notification messages from a control that you need to handle and these are sent to the controls parent window.
I have an application created with LabVIEW and I need to show/hide the application icon on the Windows taskbar at run time.
I think that WINAPI can be used for this purpose and I tried to use the ShowWindow function (user32.dll)
ShowWindow(hWnd,SW_HIDE) -> hides the application window. The taskbar icon disappears for a second than re-appears.
ShowWindow(hWnd,SW_SHOWMINIMIZED) -> It simply minimizes the application window, so the taskbar icon remains
By default a "normal" visible un-owned window gets a taskbar button and the taskbar button is visible in every state except SW_HIDE.
MSDN also documents a couple of tricks you can use to override the button:
The Shell creates a button on the taskbar whenever an application creates a window that isn't owned. To ensure that the window button is placed on the taskbar, create an unowned window with the WS_EX_APPWINDOW extended style. To prevent the window button from being placed on the taskbar, create the unowned window with the WS_EX_TOOLWINDOW extended style. As an alternative, you can create a hidden window and make this hidden window the owner of your visible window.
... If you want to dynamically change a window's style to one that does not support visible taskbar buttons, you must hide the window first (by calling ShowWindow with SW_HIDE), change the window style, and then show the window.
Another alternative is to use the ITaskbarList interface, it gives you full control over your taskbar button.
Is it possible to display the taskbar button when WS_EX_TOOLWINDOW flag is used in CreateWindowEx?
The WS_EX_APPWINDOW style is required for an unowned top-level window to display itself on the Taskbar.
The Extended Window Styles documentation specifically states that a "tool window does not appear in the taskbar".
MSDN further documents this in more detail:
The Taskbar
The Shell places a button on the taskbar whenever an application creates an unowned window—that is, a window that does not have a parent and that has the appropriate extended style bits (see Managing Taskbar Buttons, below).
...
Managing Taskbar Buttons
The Shell creates a button on the taskbar whenever an application creates a window that isn't owned. To ensure that the window button is placed on the taskbar, create an unowned window with the WS_EX_APPWINDOW extended style. To prevent the window button from being placed on the taskbar, create the unowned window with the WS_EX_TOOLWINDOW extended style. As an alternative, you can create a hidden window and make this hidden window the owner of your visible window.
The Shell will remove a window's button from the taskbar only if the window's style supports visible taskbar buttons. If you want to dynamically change a window's style to one that does not support visible taskbar buttons, you must hide the window first (by calling ShowWindow with SW_HIDE), change the window style, and then show the window.
...
Modifying the Contents of the Taskbar
Version 4.71 and later of Shell32.dll adds the capability to modify the contents of the taskbar. From an application, you can now add, remove, and activate taskbar buttons. Activating the item does not activate the window; it shows the item as pressed on the taskbar.
The taskbar modification capabilities are implemented in a Component Object Model (COM) object (CLSID_TaskbarList ) that exposes the ITaskbarList interface (IID_ITaskbarList). You must call the ITaskbarList::HrInit method to initialize the object. You can then use the methods of the ITaskbarList interface to modify the contents of the taskbar.
So, you might be able to use ITaskbarList::AddTab() for your tool window:
Any type of window can be added to the taskbar, but it is recommended that the window at least have the WS_CAPTION style.
Even when BorderStyle is set to 0, it is possible to force a window to show up on the taskbar either by turning on the ShowInTaskbar property or by using the windows api directly: SetWindowLong Me.hwnd, GWL_EXSTYLE, GetWindowLong(Me.hwnd, Win.GWL_EXSTYLE) Or Win.WS_EX_APPWINDOW. However, such taskbar entries lack a right-click menu in their taskbar entry. Right-clicking them does nothing instead of bringing up a context menu. Is there a way, to attach a standard or custom handler to it?
Without a hack, I think you're going to be stuck here, I'm sorry to say. When you set the VB6 borderless properties, you inherently disable the control menu. The control menu (typically activated by right-clicking the title bar of a window or left-clicking the icon in the upper left) is what's displayed when you right-click a window in the task bar.
Now, if you're in the mood to hack, you might be able to "simulate" the behavior in such a way that the user doesn't know the difference. I got the idea from this message thread on usenet.
Basically, it sounds like you may be able to hack it by using two forms. One form is minimized right away, and becomes your "stub" in the task bar. The other form is the one you're currently designing (which we'll call the "main" form). The stub form is what actually loads and displays your main form.
The stub form isn't borderless, and must not deactivate the control menu. It is positioned off screen and at the smallest possible size. You'll respond to its form-level events, and then use those to communicate the appropriate behaviors to the borderless form.
That's the general gist of the hack. If I wasn't at work right now, I'd whip up a simple VB6 project and see if I could get it to work for you.