## Summary
This request proposes a small set of targeted changes that would significantly improve Code Writer’s integration with Windows and modern developer workflows.
The primary goal is **not** to make Code Writer the default editor, but to ensure it can be invoked **reliably and intentionally** from the Windows shell for *any file type*, in a manner consistent with developer expectations.
---
## #1 Recommendation (Primary):
### Add “Open with Code Writer” as a Context Menu Option for All File Types
### What is being requested
Provide a first-class, supported way for users to:
> Right-click **any file** → **Open with Code Writer**
This should work regardless of file extension, without requiring:
* File association changes
* Registry hacks
* UI automation
* Default editor changes
---
### Why this should be the top priority
Developers rarely want to globally associate file extensions.
What they want is **intentional, ad-hoc editing**:
* Inspect a config file
* Open an unfamiliar file type
* Quickly view generated output
* Edit a script without changing defaults
Every mainstream editor supports this workflow.
---
### Why current behavior blocks this workflow
Currently:
* Code Writer appears in some “Open with” lists
* But file activation is not handled
* Resulting in the app opening and immediately closing, or opening without the file
This breaks user trust and makes Code Writer feel unreliable in shell workflows.
---
### How this can be implemented (minimal change)
The most robust approach is:
* Register Code Writer as a **generic “Open with” handler**
* Accept files via standard Windows activation (see Recommendation #3)
* Do **not** auto-associate extensions
This enables:
* Explorer → context menu → Code Writer
* Scripted launches using file paths
* No default editor disruption
---
### Developer workflows enabled
* Right-click any file → Open with Code Writer
* Use Code Writer as a secondary editor
* Zero setup, zero configuration
* Works for unknown or custom extensions
This single change would dramatically increase usability.
---
## #2 Recommendation: Improve `codewriter:` Protocol Handling
### What is being requested
Enhance the existing protocol handler so it can accept file payloads:
```text
codewriter://open?file=C:\path\file.ext
```
or:
```text
codewriter:C:\path\file.ext
```
---
### Why this is valuable
Protocol handling enables:
* Script-based invocation
* Deep linking from tools or documentation
* Cross-app workflows
It also provides a **fallback activation path** when Explorer is not involved.
---
### Why this is #2, not #1
While useful:
* Explorer does not use protocols for file opening
* Protocols cannot replace shell integration
* This is complementary, not foundational
Still, improving protocol handling is a **low-effort, high-utility enhancement**.
---
## #3 Recommendation: Implement `OnFileActivated`
### What is being requested
Implement standard UWP file activation handling:
```csharp
protected override void OnFileActivated(FileActivatedEventArgs args)
```
---
### Why this is required (even if not exposed directly)
This is the **core plumbing** that enables:
* “Open with” functionality
* Context menu integration
* Default app support (optional)
* Reliable file delivery to the app
Without this method:
* Windows launches the app
* But cannot deliver the file
* Resulting in immediate app exit or empty startup
---
### Why this is #3 in the list
While technically foundational, developers experience it indirectly.
From a user’s perspective:
* They want “Open with Code Writer” to work
* They don’t care how activation is implemented
However, **this method is required** to make #1 and #2 work correctly.
---
## Why AppX ProgID Should Be Used for File Associations
### The problem with classic ProgIDs
Classic ProgIDs (`txtfile`, etc.):
* Are designed for Win32 apps
* Cannot activate UWP apps correctly
* Bypass the UWP activation model
Using them leads to:
* Silent failures
* Ignored file payloads
* Inconsistent shell behavior
---
### Why AppX ProgIDs are the correct mechanism
AppX ProgIDs:
* Are explicitly designed for Store apps
* Allow Windows to route activation correctly
* Integrate with Explorer, Open With, and Defaults
* Respect UWP security boundaries
They are required for:
* Reliable file activation
* Custom file association UI
* Default app management
---
### How this supports customizable file associations
With a proper AppX ProgID:
* Code Writer can appear in “Open with” consistently
* Users can opt-in per extension
* Extensions can be added without registry hacks
* The app behaves predictably in all shell contexts
This enables **user-controlled, explicit association**, which is ideal for a code editor.
---
## Why This Enhances the Product
### From a developer’s perspective
* Code Writer becomes usable in real workflows
* It behaves like a modern editor
* It integrates naturally with Windows
* It does not force defaults or intrusive changes
---
### From a product perspective
* Minimal engineering effort
* Major usability gain
* Reduced support friction
* Better parity with free competitors
* Stronger positioning as a developer tool
---
## Final Recommendation Summary
1. **Add “Open with Code Writer” for all file types**
→ Highest impact, most visible improvement
2. **Enhance `codewriter:` protocol handling**
→ Enables scripting and deep linking
3. **Implement `OnFileActivated`**
→ Required plumbing for reliable activation
4. **Use AppX ProgID for file associations**
→ Enables customizable, supported Windows integration
---
## Closing Note
This request is not about changing Code Writer’s identity or UI.
It is about:
* Respecting Windows activation contracts
* Meeting developer expectations
* Unlocking workflows that already exist in the editor
Any/all/some of these changes would make Code Writer **significantly more usable without increasing complexity**.
