Update Volatile_Usage.md with detailed explanations

Clarify the importance of the Volatile qualifier in AutoIt callbacks and provide guidelines for object cleanup in Volatile functions.

Author: ioa747

Doc/🪽 Volatile_Usage.md

@@ -3,20 +3,28 @@
 In **NetWebView2Lib**, callback functions such as `JS_Events_OnMessageReceived` and `OnBasicAuthenticationRequested` **must** be declared using the `Volatile` qualifier. This is a technical requirement for reliable interaction between AutoIt and the WebView2 runtime.
 
 ## What `Volatile` Does
-The `Volatile` keyword enables **re-entrant execution**. 
-* **With Volatile:** While a function is running, AutoIt continues to process its internal message loop, including GUI and COM events.
-* **Without Volatile:** AutoIt pauses message processing until the function returns.
+
+The `Volatile` keyword enables **re-entrant execution**.
+
+- **With Volatile:** While a function is running, AutoIt continues to process its internal message loop, including GUI and COM events.
+    
+- **Without Volatile:** AutoIt pauses message processing until the function returns.
+    
 
 ## Why It Is Required
 
 ### 1. Continuous Message Processing
+
 WebView2 communicates with AutoIt through COM events. If AutoIt stops processing messages while handling a callback, incoming events may be delayed or blocked. Declaring the function as `Volatile` ensures that message handling continues during execution, preventing the interface from becoming unresponsive.
 
 ### 2. Synchronous COM Callbacks
+
 WebView2 event handlers are invoked through **synchronous COM calls**. This means the WebView2 process waits for AutoIt to finish executing the callback before continuing. If AutoIt is busy (e.g., during GUI interaction like moving the window), the WebView2 process may stall. Using `Volatile` allows the callback to execute without interrupting message handling.
 
 ### 3. Deadlock Prevention
+
 Because AutoIt and WebView2 run in separate processes, improper message handling can lead to deadlocks.
+
 > **Deadlock Scenario:**
 > 1. WebView2 triggers a callback and waits for AutoIt to return.
 > 2. AutoIt is blocked (e.g. by a system menu or moving the GUI) and is not processing messages.
@@ -25,46 +33,55 @@ Because AutoIt and WebView2 run in separate processes, improper message handling
 Declaring callbacks as `Volatile` prevents this by allowing AutoIt to remain responsive.
 
 ## Rule of Thumb
+
 **All functions used as WebView2 event handlers MUST be declared Volatile.**
 
-## Example
-```autoit
+**Example**
+
+```AutoIt
 ; WebView2 callback must be declared as Volatile
 Volatile Func JS_Events_OnMessageReceived($oWebV2M, $hGUI, $sMessage)
     ; Handle message from WebView2
     ConsoleWrite("Message received: " & $sMessage & @CRLF)
 EndFunc
 ```
 
-## Object Cleanup
+---
+
+## Object Cleanup & Memory Management in Callbacks
 
-In AutoIt, when working with COM objects (like the WebView2 Manager or Bridge), it is highly recommended to explicitly release the object references when they are no longer needed.
+When working with **Volatile** functions in `NetWebView2Lib`, AutoIt often receives COM objects as arguments (like `$oArgs` or `$oFrame`) directly from the WebView2 engine. To ensure high performance and stability, it is highly recommended to explicitly release these references before the function returns.
 
-### Why zero out objects?
+### Why zero out objects in Volatile functions?
 
-1. **Reference Counting:** COM objects use reference counting. The object stays in memory as long as there is at least one active reference to it. Setting `$oObject = 0` decrements this count.
+1. **Immediate Reference Release:** COM objects use **Reference Counting**. As long as AutoIt holds a reference to an object in a variable, that object stays alive in memory. By setting `$oObject = 0`, you decrement this count immediately.
 
-2. **Preventing Memory Leaks:** If a script runs for a long time and repeatedly creates objects without releasing them, it will consume increasing amounts of RAM.
+2. **Preventing Memory Leaks:** WebView2 events can fire hundreds of times (e.g., during navigation or frame changes). If these references are not cleared, your script's RAM usage will grow unnecessarily over time.
 
-3. **Proper Shutdown:** WebView2 is an external process. Explicitly cleaning up ensures that the underlying `WebView2Loader` and Chromium processes terminate correctly when your GUI closes.
+3. **Process Sync:** Since WebView2 is an external Chromium process, clearing the reference in AutoIt tells the engine that you are done with that specific resource, allowing it to clean up its own internal memory.
 
 
 ### Implementation Example
 
-Always pair your initialization with a cleanup block, typically before the script exits:
+In every **Volatile** event handler, make it a habit to nullify any object received as a parameter at the end of the code block.
 
 
 ```AutoIt
-; ... inside your Exit logic ...
+; Example: Handling a new frame creation
+Volatile Func NetWebView2_Events_OnFrameCreated($oWebV2M, $hGUI, $oFrame)
+    Local Const $s_Prefix = "[EVENT: OnFrameCreated]: WebV2M: " & VarGetType($oWebV2M) & " GUI: " & $hGUI & " Frame: " & VarGetType($oFrame)
+    
+    ; Perform your logic here
+    __NetWebView2_Log(@ScriptLineNumber, $s_Prefix, 1)
+
+    ; --- Performance Tip ---
+    ; Manually release the object reference to help AutoIt's memory management
+    $oFrame = 0 
+EndFunc   ;==>NetWebView2_Events_OnFrameCreated
+```
 
-; 1. Call the UDF's cleanup function to release internal resources
-_NetWebView2_CleanUp($oWebV2M, $oBridge)
 
-; 2. Explicitly nullify the object variables
-$oBridge = 0
-$oWebV2M = 0
+> **💡 Pro Tip:** This practice is especially important for the `$oArgs` object in events like `OnWebMessageReceived` or `OnNavigationCompleted`. Even though AutoIt will eventually clear local variables when the function exits, setting them to `0` manually is an "active" safeguard against memory fragmentation in high-frequency events.
 
-Exit
-```
 
-> **Tip:** In `Volatile` functions, if you receive an object as an argument (like `$oArgs`), it is a good habit to set `$oArgs = 0` at the end of the function to ensure the COM reference is released immediately after the event is handled.
+---