In our application, a modal dialog is shown that the user needs to confirm/close before other interaction is possible/allowed. This dialog is a self-implemented form, so can be adjusted to our needs.
An external event (in our case: a scan from a manual barcode scanner) provides input for the application. When the dialog is in front of the application, I would like to inform the user the scan/input is not processed. An idea is to simulate the behaviour that happens when clicking the form in the background of the modal dialog. By default, Windows then lets the dialog borders 'flash' and a sound is heard ('bonk' sound as described here: Delphi - How do you generate an event when a user clicks outside modal dialog?).
My question is:
Is it possible to programmatically simulate that behaviour, in order
to let user know the dialog has to be closed first?
Additional question: is this proper UI handling or should the dialog itself display an additional info text (e.g. as a footer text) instead of just 'flash'. I like to avoid displaying another modal dialog on top of the first one; to me that not seem best practice as well.
Thank you for any feedback/solution.
Use the FlashWindow or FlashWindowEx functions to achieve this.
Related
I have a custom task pane and now I am trying to catch the close event of the custom task pane. I have seen that there is no such event, instead there is the VisibleChanged event with does exactly the same, it is raised when visibility changes or it is closed.
When user clicks on close button or select close from the context menu, I would like to display a messagebox saying it is not permitted to close it and not allow user to close it.
I have seen an approach here or this user a thread but this is causing flickering when showing it again (you can see that it is hidden and then make visible again quickly). Is there any other way to achieve this? Also where is the best place in those approaches to show the messagebox?
Custom task panes don't provide any event which is fired when the pane is about to close. There is no trivial way to get the job done, you need to implement workarounds described on forum threads. Also you may consider using Advanced Outlook view and form regions instead.
Note, Outlook form regions provide the following events out of the box:
Event
Description
FormRegionInitializing
Occurs before the form region is initialized. You can check conditions in this event handler to determine whether Outlook should display the form region. For more information, see How to: Prevent Outlook from displaying a form region.
FormRegionShowing
Occurs after an instance of the form region is created but before the form region appears.
FormRegionClosed
Occurs before the form region is closed.
I have application that currently not active. On timer event I need to show this application selection form (yes/no) to user. This form must have keyboard input focus.
What function I must use to make currently not active application form active? SetWindowPos, SetFocus does't help. SetWindowPos - shows form, but is still has no focus.
Probably first of all I need to make whole application active?
When form is shown to user and user has done selection how to bring focus back to application that had it before timer event?
Application is created using MFC.
The answere to your first question is yes, you have to make your whole application active.
To put your window at the top level with input focus you can use BringWindowToTop.
To know wich is the current top window you can call GetTopWindow with NULL.
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 want to create a custom NSWindow that acts as a modal dialog. By custom I mean it has normal user controls in the window, with a "OK" and "Cancel" buttons. The dialog will contain read only information, and have a few checkboxes, secure edit fields, etc.
The MainMenu.xib file will have the normal Window visible at launch, plus include the custom NSWindow (which is NOT visible at launch).
I am trying to find example code to launch the window in modal mode (after the app initializes and launches main window), and on "OK" run a process, and on success of that process hide the dialog. Or on failure, keep the dialog up, but show an error sheet on the dialog.
Any help is appreciated, thanks.
You want to look at NSApplication’s -runModalForWindow: and/or -runModalSession: methods. Note that using modal windows is generally a bad idea and if it’s at all possible to avoid doing so, you should; that said, sometimes needs must.
As far as launching a process, waiting for it to finish and so on, you can probably do what you need with NSTask, although you don’t provide sufficient detail to be certain. You’d probably want to observe NSTaskDidTerminateNotification to tell you when the task had finished.
See
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/OperatingSystem/OperatingSystem.html
for more on NSTask and
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/WinPanel/Concepts/UsingModalWindows.html%23//apple_ref/doc/uid/20000223-CJBEADBA
for more about modal NSWindow usage.
Have a look at NSApplication's -runModalForWindow: method, and "Using Application-Modal Dialogs."
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.