The behavior you’re seeing is expected in ODC with blocks + events: all client logic (including UI updates) is executed as one “transaction” before the screen is re‑rendered, and once you trigger a block event, control moves to the parent flow. That’s why:

• The LoadingButton state doesn’t update before the parent event finishes. ODC: Button Loading inside block doesn't show spinner when calling a block event
• The Popup only closes when the whole request finishes.
• The button can still be clicked until the next render actually happens.

Below is how to fix this and what pattern to use.

1. Why the LoadingButton and UI updates don’t apply

When you do this inside the block:

1. IsLoading = True
2. Trigger Event to parent
3. IsPopupVisible = False

the event immediately transfers execution to the parent action, so steps 1 and 3 never get a chance to be reflected in the UI before the long‑running logic completes. ODC: Button Loading inside block doesn't show spinner when calling a block event

This is the same situation described in the article you referenced: the “loading” logic needs to run where the actual work is being done (i.e., in the parent), not in the publisher block. ODC: Button Loading inside block doesn't show spinner when calling a block event

2. Recommended pattern to show loading and prevent multiple clicks

Use an input parameter (e.g., IsSaving) on the event and manage the loading state in the parent that subscribes to the event. This is the same pattern suggested in the forum solution. ODC: Button Loading inside block doesn't show spinner when calling a block event

Step‑by‑step restructuring

In the Block:

• Do not set IsLoading or close the Popup inside the block’s click handler.
• The block only:
  • Raises the event.
  • Uses input parameters for:
    • IsSaving (Boolean) → bound to LoadingButton.IsLoading and Button.Enabled.
    • IsVisible (Boolean) → bound to the Popup’s visibility or input of the popup widget.

So something like:

• Block Inputs:
  • IsSaving: Boolean
  • IsVisible: Boolean
• Button:
  • ButtonLoading.IsLoading = IsSaving
  • Button.Enabled = not IsSaving
• Popup:
  • Visible = IsVisible
• OnClick of button:
  • Only trigger OnConfirm event (no local assigns).

In the Parent Screen:

• Have local variables:

  • Popup_IsVisible: Boolean
  • Popup_IsSaving: Boolean

• Bind block inputs:

  • IsVisible = Popup_IsVisible
  • IsSaving = Popup_IsSaving

• In the parent’s event handler (subscriber):

  1. Popup_IsSaving = True
     (Loading spinner appears & button is disabled before any heavy logic runs.)

  2. Execute your long‑running logic:

     • Call server actions, timers, etc.

  3. When finished:

     • Popup_IsSaving = False
     • Popup_IsVisible = False (close the popup)

If needed, set Popup_IsSaving = False also in exception handling, like communication errors, so the UI does not remain stuck in loading. Prevent users from spam clicking buttons

This way:

• The loading state is controlled where the work happens.
• Button is disabled by IsSaving → prevents multiple clicks.
• Popup close is explicitly controlled at the end of the parent logic.

This is effectively the same pattern you use in other “prevent multiple clicks” scenarios (boolean bound to Enabled + LoadingButton), just split between block and parent. Prevent user from clicking too fast on several buttons and links

3. Why your “Enabled” and “Visible” toggles didn’t work

When you tried:

• Button.Enabled = SomeLocalFlag then set it to False inside the block, or
• Container.Visible = SomeFlag and set it to False,

you still had the same problem: the assigns occur in the same client‑side execution cycle as the event trigger. The UI only re‑renders after the entire chain (block + parent event) finishes. So you cannot rely on local block state changing after the event has been triggered and expect an immediate visual update.

That’s why the fix is to:

• Move the state ownership (IsSaving, IsVisible) to the top‑level container (parent screen),
• And have the block only reflect that state via inputs instead of trying to control it internally.

4. Best practices for popup closing vs parent execution timing

Depending on UX requirements, you have a few patterns:

1. Close popup after all processing completes (simplest)

   • As described above: show loading + disable button, run logic, then close popup at the end.
   • Good when user must wait for the operation to finish.

2. Close immediately, process in background

   • In parent event handler:
     • Immediately set Popup_IsVisible = False
     • Optionally show a page‑level loading overlay or “toast” saying “Processing…”
     • Then run the heavy logic.
   • Useful if you want the screen “released” quickly.

3. Global “overlay” to block everything

   • Use a full‑screen container with a semi‑transparent background + spinner, controlled by another Boolean IsGlobalLoading. Creating popup with Loading, how?
   • When operation starts: IsGlobalLoading = True.
   • When operation ends: IsGlobalLoading = False.
   • This prevents any other clicks during critical operations. Prevent user from clicking too fast on several buttons and links

Whichever you choose, keep the rule: UI state is handled at the consumer (parent), not inside the reusable block once events are involved. This matches the recommended approach in the referenced ODC thread and is what will make your LoadingButton behave correctly. ODC: Button Loading inside block doesn't show spinner when calling a block event