Tool Dialog Prompts

Dialog prompts are an essential part of Tool Integration Development and Services in EiffelStudio. As such we have provide a number of EiffelStudio specific classes for creating and displaying EiffelStudio dialog prompts.

Consistent Look and Feel

As of EiffelStudio 6.1 (EiffelStudio 6.1 Releases), EiffelStudio uses custom dialog prompts that come in a flavor of presentation that stands above the stock dialog prompts found in EiffelVision2. As such all dialog prompts in EiffelStudio should be using the new prompt classes instead of those found in EiffelVision2 or the slightly specialized versions found in previous versions of EiffelStudio.

Just to get an idea of what the new prompts look like, here’s an example:

New Features

The new dialog prompts in EiffelStudio no only have an update look and feel to them but the come with a number of added benefits for both end-users and EiffelStudio tool developers:

• Brand new look.
• Automatic layout of widgets and other text.
• Button layouts are platform-dependent (Ok|Cancel on Windows, Cancel|Ok on Mac OSX.)
• Dual-model; providing agent actions to perform on button presses and/or retrieval of the dialog result code.
• Simplified interfaces with less code to write.
• Extendable (see ES_DISCARDABLE_COMPILE_SAVE_FILES_PROMPT.)
• Provides both standard and advanced creation routines for quick or complex creation.
• An abstraction that makes it easy to replace the prompts in the future, updating the look etc.
• Dialog prompts are always modal to the parent window.
• Automatic location of the last active EiffelStudio window so tools need not worry about window management.
• Automatic key navigation binding; Use of TAB, LEFT or RIGHT cursor keys and button first(or next)-character key (Yes => Y, Create => C, ...)
• Ability to set a default active button.

Choosing a Dialog Prompt

Making the correct choice as to which dialog prompt to display is crucial, and is not as easy as you think. There is a page dedicate to deciding what dialog prompt is best suited for the need of a particular message - Taxonomy of Dialog Prompts. For help on choosing and formatting dialog prompt messages, see Dialog Prompt Messages and Formatting.

Displaying Dialog Prompts, the Easy Way

Instead of creating dialog prompts and displaying them using the ES_XXX_PROMPT classes directly you can use a help class ES_PROMPT_PROVIDER (or inherit the shared class ES_SHARED_PROMPT_PROVIDER and access prompts.) Of course, the easy way does limit functionality but for the vast majority of cases the routines of ES_PROMPT_PROVIDER provide all that is needed.

Note: For tool and dialog development ES_DOCKABLE_TOOL_WINDOW and ES_DIALOG both inherit ES_SHARED_PROMPT_PROVIDER and provide access to a shared instance of ES_PROMPT_PROVIDER through a feature prompts.

ES_PROMPT_PROVIDER provides a quick means to display dialog prompts and associate any actions with the default buttons created on the prompts. The routine are self explanatory, Each routine shows the prompt specific to the situation, show_error_prompt will show an error prompt, show_warning_prompt shows an warning prompt, show_info_prompt shows an information prompt and finally, show_question_prompt show a prompt designated for asking the user a question.

There are the show_xxx_with_cancel variants, which includes a cancel button along with the standard set of buttons.

Prompt Arguments

Using ES_PROMPT_PROVIDER does not provide any means to custom the dialog prompts instead its purpose is for the quick creation and display of standard dialog prompts.

Every show_xxx_prompt routine requires a message string through the parameter a_message, which relates to the message the user is shown.

The argument specifying the parent window, through the parameter a_window, to display the prompt to is optional. If Void is passed for this argument then the last focused window/dialog is used as the parent window or the last active EiffelStudio IDE main window.

The other routine arguments are for any actions that should be associated with a button press in the prompt. Simply pass an appropriate agent or Void to specify no action. There is a parameter for each of the standard buttons.

An Example, the Easy Way

To simply demonstrate the use of ES_PROMPT_PROVIDER by inheriting the shared class ES_SHARED_PROMPT_PROVIDER, the code below is all that is needed to show an Error prompt on the IDE window, with the message "This is an Error prompt".

prompts.show_error_prompt ("This is an Error prompt", Void, Void)

The result of executing the above code results in a dialog prompt like the one below:

To get a little more into prompts, here's a confirmation prompt that performs actions when pressing a button. Note, inline agents are used here just for the purpose of brevity.

prompts.show_question_prompt ("If you press Yes, I'll tell you something...", Void,
  agent
    do
        -- Agent action for 'Yes' button.
      prompts.show_info_prompt ("You pressed Yes!", Void, Void)
    end,
  agent
    do
        -- Agent action for 'No' button.
      prompts.show_error_prompt ("You should have pressed Yes!", Void, Void)
    end
  )

The result of executing the above code results in a dialog prompt like the one below:

Pressing the Yes button on the question dialog prompt produces the dialog prompt:

Pressing the No button on the question dialog prompt produces the dialog prompt:

Using Dialog Prompts In the Eiffel Framework

ES_PROMPT_PROVIDER and ES_SHARED_PROMPT_PROVIDER are accessible from the Eiffel framework library, however the underlying implementation in the framework library actually uses the older EB_XXX_DIALOGs instead of the new ES_XXX_PROMPT classes.

The new ES_XXX_PROMPT rely on classes found in the EiffelStudio IDE so for the sake of compatibility the old EB_XXX_DIALOG classes have not been removed from the framework. This means when you are developing with the framework library outside of the EiffelStudio (target bench) project you will see the older dialog prompts, this is normal. Once your code is integrated into the EiffelStudio project, even if it is referenced as a library by the project, you code will automatically use the new dialog prompts for EiffelStudio. Under no circumstances should you be using the EB_XXX_DIALOG dialog prompt classes directly, please use the routines of ES_PROMPT_PROVIDER.

This transparent switching of implementation is accomplished by using an override cluster in the EiffelStudio (target bench) project, overriding the default implementation in the framework library with the EiffelStudio specific implementation.

Note: The transparent switching is done through overriding the default implementation of ES_PROMPT_PROVIDER and not any of the EB_XXX_DIALOG classes! If you use the EB_XXX_PROMPT classes directly you will see no change with integrating you code. All the EB_XXX_PROMPT classes have been marked obsolete so the only obsolete warnings you should see if those from ES_PROMPT_PROVIDER.

Displaying Dialog Prompts, the Other Way

If more control is what you are after then using the ES_PROMPT_PROVIDER may not be of any use. As such you can instantiate, use and display the EiffelStudio prompt classes directly.

There are, as of EiffelStudio 6.1, four common dialog prompt classes for use which are self-explanatory.

• ES_ERROR_PROMPT: Used to display a error.
• ES_WARNING_PROMPT: Used to display a warning
• ES_INFORMATION_PROMPT: Used to display a piece of informative text.
• ES_QUESTION_PROMPT: Used to ask the user a yes/no question.

Each dialog prompt class provide two or more creation routines; make and make_standard. Some prompt classes also have an addition creation routine, make_standard_with_cancel, to augment the standard button set with a Cancel button. The creation routine make offers the most control but requires more information to create the dialog. The make_standard creation routines are simpler and only require a dialog prompt message.

The make_standard creation routines initialize the dialog prompt using a standard set of dialog buttons in the order dictated by the executing platform. The standard dialog buttons are as follows (ordering representative on Windows):

• Error: Ok
• Warning: Ok
• Information: Ok
• Question: Yes|No

As mentioned, some of the prompts come with a third creation routine, make_standard_with_cancel, augmenting the existing dialog prompt's button set with a Cancel button. The only dialog prompt not to have a third creation routine is the Error prompt as an error is usual considered an exception case and general there is no recourse action. The standard dialog buttons "with cancel" are as follows (ordering representative on Windows):

• Warning: Ok|Cancel
• Information: Ok|Cancel
• Question: Yes|No|Cancel

Button Sets

Most dialog prompts have a standard set of buttons and being so ES_DIALOG_BUTTONS provides access to the well-known and commonly used button sets, such as Ok|Cancel, Yes|No and even Abort|Retry|Ignore.

Note: All dialog prompts inherit ES_SHARED_DIALOG_BUTTONS through the base dialog implementation ES_DIALOG (see Tool Dialogs for more information on ES_DIALOG and dialog button sets.)

Two Consequence Models

As stated above in the New Features section the ES_XXX_PROMPT classes proffer two models based on the consequence of a user's interaction with the dialog prompt.

Agent Assignment

The primary model is the use of agents, assigning them to a button using a button identifier.

After creating a prompt you may associate an agent to a button using ES_PROMPT.set_button_action. The routine takes a button identifier, which must be an identifier of a button on the prompt, as well as an agent action.

ask_save_changes
    -- Ask user if they want to save the changes before continuing
  local
    l_prompt: ES_QUESTION_PROMPT
  do
    create l_prompt.make_standard ("Save changes before continuing?")
    l_prompt.set_button_action ({ES_DIALOG_BUTTONS}.yes_button, agent save_changes)
    l_prompt.show_on_active_window
  end
 
save_changes
    -- Save all changes
  do
    ...
  end

In the example a question prompt was created using the standard set of buttons for question prompts, which in this case are Yes and No buttons. Post-creation and initialization the Yes button is assigned an agent through the call to set_button_action. set_button_action is passed the button identifier yes_button, which is statically accessed from ES_DIALOG_BUTTONS. yes_button could have just as easily been accessed from the dialog_buttons function exported on the prompt class:

l_prompt.set_button_action (l_prompt.dialog_buttons.yes_button, agent save_changes)

However, static access if preferred if appropriate for the situation.

Using Dialog Result

The second model of processing actions or changing execution flow, based on the user's interaction with the dialog prompt, is through the result dialog_result. Like button identifiers, dialog_result is an INTEGER and is set once the dialog has been closed buy the result of a user's interaction.

Here is the same example written using the dialog result model.

ask_save_changes
    -- Ask user if they want to save the changes before continuing
  local
    l_prompt: ES_QUESTION_PROMPT
  do
    create l_prompt.make_standard ("Save changes before continuing?")
    l_prompt.show_on_active_window
 
    if l_prompt.dialog_result = {ES_DIALOG_BUTTONS}.yes_button then
      save_changes
    end
  end
 
save_changes
    -- Save all changes
  do
    ...
  end

Using static access for the dialog button identifiers also allows you to opt to use the Eiffel inspect construct instead of using if...then...elseif...then...end:

inspect l_prompt.dialog_result
when {ES_DIALOG_BUTTONS}.yes_button then
  save_changes
when {ES_DIALOG_BUTTONS}.no_button then
  do_something_else
end

Discardable Dialog Prompts

Showing dialog prompts showing the same messages over and over again can be annoying for some, if not most. Take the security or alert notifications in your browser, most of us just turn them off after we have read them after they have been shown for the first time. EiffelStudio is full of cases where "discardable" dialog prompts are useful as not to hinder or annoy end-users. One such prime example is performing a finalization compilation. Finalization asks the end-user if they want to discard or keep assertions. For the most part (95%-99% of cases) assertions are always discarded. It makes sense to offer a way to suppress the dialog in the future and perform a default, commonly used, pre-defined action (discarding assertions in this case) when performing a finalization in the future.

Like the regular dialog prompts, discardable dialog prompts can also be extended. For an example of extension inside EiffelStudio, see the ES_DISCARDABLE_COMPILE_SAVE_PROMPT class.