Is it possible to close the options dialog popup once the extension is run?
I feel it's kind of silly to have the options dialog hang in there once you've pressed "apply" (though not in all circumstances).
For clarity - this is an example of the dialog. Once you press apply, it just stays there and stares back at you.
Related
It's a dialog based MFC application. I didn't intentionally add any code about the Minimize, Maximize and Restore button. It can show those button at the first. But it just disappear after long time running. Or maybe sleep of the computer causes this?
I have no idea about this, do you have any clue?
Edited:
Thanks #xMRi's remind, I checked its style, seems still to be right.
Listed below few possible reason & resolution may impact you application look. More specifically, your device manager plays important role in application appearance. I would say its environment or certain unnecessary application(Virus)installation issue rather than your MFC application issue.
Full Fix: Minimize, Maximize and Close Buttons Disappear
At least I know a way to restore the disappared system buttons.
ModifyStyle(0, WS_MINIMIZEBOX);
GetSystemMenu(FALSE)->InsertMenu(-1, MF_BYPOSITION, SC_MINIMIZE, _T("Minimize"));
Press F11 for Windows 10, or right-click on the application which you can't see windows button then choose view finally uncheck the full screen
Is it possible to alter the layout of the tool-bar icons?
The 'Continue' icon is right next to the 'Stop Debugger' icon, which is a really bad design and I've lost count of the number of times I meant to click continue but have accidentally clicked on the 'Stop Debugger' icon.
To my knowledge it is not possible to rearrange the buttons in the current build.
You have two options:
Build Qt-Creator (or at least the "Debugger Plugin") from Source, and change the UI to your liking.
Open a feature request on https://bugreports.qt.io/ and convince enough people to vote it up.
Consider using the keyboard short cuts. If you can't use a keyboard, consider using the fat "Run" button on the left bar which becomes a Continue button when stopped. This is ~300 pixels away from anything that could Stop debugging.
I'm using the MessageBox function provided by the Win 32 framework to display a Yes and No message box. I need to keep enabled the close button (the X in the top right corner) but unfortunately seems that is available only when the window contains also a Cancel button.
Is it true or there is some other way to achieve this?
The message box design reflects the platform UX guidelines. In a modal dialog, if you present a close button, the user needs to have a clear expectation of what action that button provokes. And the platform UX guideline is that the close button performs the cancel action.
So, that is why the close button is enabled if and only if the dialog presents a cancel button. This design allows the user to be confident that when they press the close button, the action relating to the dialog will be cancelled.
There is no mechanism provided by the API to subvert this UX design in the standard message box. If you are keen to offer your own UX design, that varies from the platform UX standard, then you can create your own dialog and use that. Once you create your own dialog, you are able to enable or disable whatever buttons you please.
However, I urge you not to do this.You intend to present a dialog with a yes/no question and have the close button be used to mean either no. That is counter to the prevailing platform UX and will be confusing to users. If the cancel action is not meaningful, then do not offer a close button since the close button means cancel.
How would one prevent the little dotted square that appears on a button when it has the keyboard focus in a dialog. (w/ apologies for the technical jargon). At one point I hacked together a solution by subclassing a button WindowProc and subverting some windows messages, but wanted to know the correct way.
There's actually a problem with another control in the dialog also involving the keyboard. This other control is actually also a button, but being used as a group box or panel, not as a functioning button. But when I hit the tab key in the dialog, this group box "button" comes to the foreground obscuring the static controls on top of it, so I wanted to prevent that.
For both of the above, I tried turning off WS_TABSTOP - didn't help.)
Both of my problems mentioned above were solved by subclassing the WndProcs and returning 0 in response to message 0x128 and discarding it. Even Spy++ could not identify this message 0x128, and I don't have it in any header. But its sent to every control in the dialog the first time tab is hit in the dialog.
(I did try BN_SETFOCUS as described above and also WM_SETFOCUS but it didn't help.)
So if anyone knows where to find what windows message 0x128 is...
The correct way is to write your own button control instead of using the default Windows one.
Alternatively, you can prevent if from ever getting keyboard focus.
I currently have some toolbar buttons with a small arrow on the side (TBSTYLE_EX_DRAWDDARROWS) that, when clicked, result in a popup context menu being displayed under the button. This is done by constructing a custom popup menu and calling TrackPopupMenu.
The client now wants to be able to select multiple options from the menu before it closes, so that multiple options can be be modified without the need to re-open the menu and wait for an intermediate redraw between each change.
For example:
User clicks dropdown button
Dropdown menu appears (modal, waits indefinitely for user action)
User clicks some item (e.g., toggle a checkmark)
Timer (e.g., 500ms) starts
If timer expires, the menu is closed and all selected actions are executed.
User clicks another item before the timer expires, go back to 4.
The best I can come up with is to redisplay the menu by calling TrackPopupMenu multiple times. This makes the menu "flicker" when you select an item, and will probably require me to start a thread in order to do the timeouts, which I would rather avoid.
Rather than a menu, put up a dialog box with the options on it. A dialog can easily do all that is required.
A menu that doesn't close when you click it will just seem wrong. A dialog that closes by itself will seem wrong too, but it's probably the least of two evils.
Edit: If there's anything I've learned with Microsoft, it's don't try to fight the default behavior. You're asking for trouble if you do.
If you're building your menu dynamically I can see how automatic sizing can be handy, but it's not hard to do in a dialog either - make the dialog really big and before it becomes visible, enumerate the children and take a union of all their rectangles, then resize to that. Checking the boundaries to make sure they're on-screen is just a few if statements with OffsetRect. Checkboxes are trivial; icons less so, but still not bad.
One additional enhancement that would be easy to add is to dismiss the dialog immediately on a double-click.
Following #Mark Ransom's answer, you should put up a dialog box. But you can make the dialog modeless and make it close itself when you click outside of it (i.e., the dialog loses focus). That way it could behave more like a menu.
Notice that normal menus never go away by themselves, you always have to click somewhere outside the menu (or one of its options) to make it disappear.