From 4eb1a2a31b294e94e9d259f28ebcb4e026e99f20 Mon Sep 17 00:00:00 2001 From: Karol Lewandowski Date: Wed, 10 Apr 2024 10:35:01 +0200 Subject: [PATCH] general_threading_rules.md: Fix header levels --- .../architectural_overview/general_threading_rules.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/topics/basics/architectural_overview/general_threading_rules.md b/topics/basics/architectural_overview/general_threading_rules.md index 311159da6..cdbf6e9e2 100644 --- a/topics/basics/architectural_overview/general_threading_rules.md +++ b/topics/basics/architectural_overview/general_threading_rules.md @@ -79,17 +79,17 @@ The latter API allows specifying the _modality state_ ([`ModalityState`](%gh-ic% The operation will be executed after all modal dialogs are closed. If any of the open (unrelated) projects displays a per-project modal dialog, the action will be performed after the dialog is closed. -#### `ModalityState.stateForComponent()` +### `ModalityState.stateForComponent()` The operation can be executed when the topmost shown dialog is the one that contains the specified component or is one of its parent dialogs. -#### None Specified +### None Specified `ModalityState.defaultModalityState()` will be used. This is the optimal choice in most cases that uses the current modality state when invoked from UI thread. It has special handling for background processes started with `ProgressManager`: `invokeLater()` from such a process may run in the same dialog that the process started. -#### `ModalityState.any()` +### `ModalityState.any()` The operation will be executed as soon as possible regardless of modal dialogs. Please note that modifying PSI, VFS, or project model is prohibited from such runnables.