I want to create a control in WinAPI which works like some toolbar buttons do: you can click the button but it cannot be focused; the focus stays on the control that had it. How do I go about it?
This is not a complete answer because I've abandoned the task eventually, but what I found is that in fact, controls have to SetFocus(Self) manually and they usually do that in WM_LMOUSEDOWN handlers.
So to handle clicks like toolbar buttons do, it's enough to not do that.
Problem is, standard controls and common frameworks usually do this automatically deep in their internals. With frameworks such as MFC or VCL it might be possible to hack this off somehow, standard WM_LMOUSEDOWN handler for BUTTON control seems to do SetFocus, and it can't simply be skipped because it also does click processing.
Related
Is it usual to use a Dialog as main Windows? So without registering any user class via RegisterClassEx? Can I do everything I do via CreateWindow()? Why should I create controls such as buttons,editboxes etc via CreateWindow() instead of just making a Dialog and use it as main Window?
I'd also like to know main difference between a dialog and a windows and why use one the first instead of the second.
Thanks
Is it usual to use a Dialog as main Windows?
Yes, it is quite common.
So without registering any user class via RegisterClassEx?
A dialog is usually a predefined window class, so there usually no need for registering.
I'd also like to know main difference between a dialog and a windows and why use one the first instead of the second.
Well, two big differences would be that you cannot resize a dialog box and it has no minimize or maximize buttons (by default, but there are workarounds for this). Keep in mind the name, dialog box. In other words they are used for having a dialog with the user (receive input and displays messages to user). In a sense they are just like any other window, underneath CreateWindowxx, etc. is called, etc. However, they are somewhat predefined windows which can be made quickly and there are limitations to what you can do with them.
Also, a dialog uses a dialog procedure rather than a window procedure, which does some default processing for you, such as initializing some controls, etc.
Yes, an application can be dialog-based. There's even a Wizard for that if your'e using VisualStudio and MFC.
In VS2010, Create New Project > MFC Application. In "Application Type" select Dialog Based. Click through the rest of the Wizard, and you're off to the races.
Dialog-based applications are much simpler, architectually, than other designs such as Document/View. As such, simple things are much easier to "bang out" quickly, but the limitations of the design become apparent when you try to do more complex things. You could end up replicating much of the Doc/View architecture in your dialog-based app in order to build a production-quality Dialog-based application. In that case, did you really save yourself anything?
A dialog is a kind of window just as all of the various controls like buttons are really just windows. You can think of a dialog as being a kind of window with a lot of extra functionality to support the kinds of things that dialogs are used for.
There are two types of dialogs, modal which display and expect you to use them and then dismiss them, and non-modal which display but which do not capture and keep the input focus until they are dismissed. You can see these two types used in applications where a modal dialog is used to display an error or require the user to make some setting and a non-modal acts as a kind of tool box that stays displayed and when you need it, you click on it to do something and other times you are using some other window in the application.
Normally a dialog would not have a menu bar but would instead have all of its controls visible or easily accessible via tabs or some other type of presentation. Visual Studio and other IDEs have dialog designers to allow the placement of various controls along with wizards to allow the controls to be tied to classes and class members.
Which brings up a major difference between a dialog and a window. A window is kind of an empty page and to do things with the page requires more work. A dialog has tools that make the design easy however you are also constrained in large part by the toolbox.
If you have an application that is focused on basically allowing a user to specify certain settings and then do some task, a dialog works fairly well. If you have something that requires more complicated user interaction, an application window as the base from which all of your other dialogs and controls will be managed and manipulated will be more necessary.
I would like to add my custom command, to a window system menu (the one usually on the left top on titlebar, usually containing Minimize, Maximize and so on), and respond to it in my application.
In ms windows one can do
HMENU hMenu = GetSystemMenu(hwnd, false);
AppendMenu(hMenu, MF_STRING, ...)
Is something like this possible under X11? If not a general method maybe a solution for some specific window manager?
Ok, after your last edit, what I understand is that you want to add your custom menu to the menu that's on the window decoration, which is controlled by the Window Manager.
I don't think that's possible, although I'm not sure. I believe you should read the ICCCM and the EWMH to find if this is possible or not:
http://en.wikipedia.org/wiki/Inter-Client_Communication_Conventions_Manual
http://en.wikipedia.org/wiki/Extended_Window_Manager_Hints
Or you can send an email to wm-spec-list asking:
http://mail.gnome.org/mailman/listinfo/wm-spec-list
Also, adding an option there makes it quite hidden, doesn't it? I guess most people don't ever click that menu... I don't even think that menu exists on all the possible Window Managers. You should really try to put your menu inside your application's Window instead of the Window Manager's decoration. Some environments don't even have Window Managers: what would your users do in this case?
Note that some applications (like the Chromium browser) don't use the Window Manager decorations: they implement their own decoration, they implement their own close/maximize/minimize buttons. This way, they have complete control over all the decoration buttons and menus, but their decoration doesn't have the same "look and feel" of the rest of the desktop. You could think about doing this, but I wouldn't encourage that... You should probably put your menu somewhere else (where it's not that hidden...).
You mean you want to add your app to the system menu?
I believe most modern desktop environments implement the XDG Menu Standard:
http://standards.freedesktop.org/menu-spec/menu-spec-latest.html
You'll have to learn other standards too probably:
http://standards.freedesktop.org/
They're all somehow short, so they won't consume more than some hours to read and learn.
I am using SketchFlow for a prototype. Right now when the user clicks certain 'links' a trigger is excuted which calls navigatetoscreenaction and I supply the target screen. The problem is instead of going to this screen and leaving my main window, I want my target screen to popup into a modal dialog. Can you accomplish this with Sketchflow?
Yes, but you might have to code it up yourself. If you truly want a dialog you will have to do it in the event handler for the item you are clicking. You would do it just like any other dialog on the platform you are using.
If you just want to simulate it, you could make the screen into a component screen and use visual states to hide/show it. Made it hidden in the base state, and create a show state that you trigger with a behavior.
yes you sure can, with a component screen. Right click on your source screen in the sketchflow map and there it is.
Firefox has this nice find-a-text-on-the-page dialog, which is non-modal and shows up at the bottom of the window. How to do something similar using just Win32? I guess there has to edit control but do I have to position it manually on parent window WM_SIZE? How do I dismiss the dialog, i.e. how to make it disappear?
As said above, use a rebar and put an edit control and the buttons that you need on it. You'll have to manage all the rest yourself, manually (close button, showing/hiding it, etc.).
I guess that is what you call a rebar...http://msdn.microsoft.com/en-us/library/bb774373(VS.85).aspx. Google if you need more info...
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.