Req: Ctrl+backspace to delete from cursor position

[lanux128]

currently when using Ctrl+backspace to delete the previous word, Farr starts from the end of the line regardless of the cursor position. can Farr be made aware of the cursor position and delete from that position?

[ewemoa]

I would like this too.  I think something similar was mentioned at:

  https://www.donation...ex.php?topic=18120.0

Here's a little hack to demo the desired behavior:

  http://ewemoa.dcmemb...FARRCtrlBSDelFix.exe

SHA1: 8cbc04eaf82a8b403657e94366afe887d4a08a70

Control+Delete behavior is also changed.  It's a quick hack so be warned

(It's done using AutoHotkey_L in case you feel like decompiling, messing around and recompiling.)

[mouser]

can you fellows truly be planning to use such an odd feature?

[skajfes]

can you fellows truly be planning to use such an odd feature?

-mouser (May 11, 2010, 07:47 AM)

Why not? It is standard behavior for all text boxes in windows (as far as i can tell) and I use it very often, along with other shortcuts (ctrl + del, ctrl + left, ctrl + right, ctrl + shift + del...), so it is a bit confusing when FARR (launcher for keyboard manics) doesn't work as expected.

[ewemoa]

I agree with skajfes and present exhibit A:

  https://www.donation....msg195526#msg195526

[lanux128]

I would like this too.

-ewemoa (May 11, 2010, 07:39 AM)

thanks ewemoa, much appreciated.

[ewemoa]

Hope it works out ok for you.

More detail than you probably care for

The code is a modification of one of the AutoHotkey_L examples for its #If directive and should apply to all TEdit controls.

I've made a version which also checks that the window is of class TMainForm, so if the first version gives any trouble, there's something else to try

[lanux128]

Hope it works out ok for you.

-ewemoa (May 12, 2010, 08:37 AM)

thanks again for this script as it comes in handy when i'm using a live search plugin in Farr (e.g. Google Plus or FarrWebMetaSearch).

btw, you dropped a hint when you mentioned AutoHotkey_L since it has the #If command. but i wonder if this works with multi-line edit control?

[ewemoa]

As I understand it, the way this works has to do with the class of the control (and now also that of the window the control lives in).  If those match, it seems like it may work.  For reference:

  http://www.autohotkey.net/~Lexikos/AutoHotkey_L/docs/commands/_If.htm

Here is the source of the latest (not uploaded version)

Code: AutoIt [Select]

1. #If ActiveControlIsOfClassAndWindowIsOfClass("TEdit", "TMainForm")
2. {
3.   ^BS::Send ^+{Left}{Del}
4.   ^Del::Send ^+{Right}{Del}
5. }
6. #If
7.  
8. ActiveControlIsOfClassAndWindowIsOfClass(CClass, WClass)
9. {
10.   ControlGetFocus, FocusedControl, A
11.   ControlGet, FocusedControlHwnd, Hwnd, , % FocusedControl, A
12.   WinGetClass, FocusedControlClass, % "ahk_id " . FocusedControlHwnd
13.   WinGet, Hwnd, ID, A
14.   WinGetClass, FocusedWindowClass, % "ahk_id " . Hwnd
15.   Return (FocusedControlClass = CClass) and (FocusedWindowClass = WClass)
16. }

You may have noticed that this code may apply for some non-FARR apps too.

[lanux128]

thanks for the source.. i'm already using your "Select All" script, this one is also within that scope. soon we can have an ewemoa's compendium for better text editing.

[lanux128]

i found a program (mIRC) where this scripts doesn't work.. as you can see in the screenshot. it's focused on the edit control but Ctrl+Backspace doesn't work. maybe you can work your magic here.

[ewemoa]

i found a program (mIRC) where this scripts doesn't work..

-lanux128 (May 13, 2010, 09:09 AM)

Well it is not surprising to me  The current code is deliberately made to be a bit focused on where it's supposed to work.

FWIW, the code from which this descends only checked controls with class "Edit".  FARR doesn't use that for its main edit box IIUC, so I changed what it checks for.  I also modified it to check the window class as the original request was for FARR and I didn't want this to affect too many other things.

I agree that a more general tool would be interesting, but haven't given it much consideration yet.

Don't know if you have AutoHotkey_L to test, but may be this will work...not as a replacement tool, but as something temporary to run separately as a test

Code: AutoIt [Select]

1. #If ActiveControlIsOfClassAndWindowIsOfClass("Edit", "mIRC")
2. {
3.   ^BS::Send ^+{Left}{Del}
4.   ^Del::Send ^+{Right}{Del}
5. }
6. #If
7.  
8. ActiveControlIsOfClassAndWindowIsOfClass(CClass, WClass)
9. {
10.   ControlGetFocus, FocusedControl, A
11.   ControlGet, FocusedControlHwnd, Hwnd, , % FocusedControl, A
12.   WinGetClass, FocusedControlClass, % "ahk_id " . FocusedControlHwnd
13.   WinGet, Hwnd, ID, A
14.   WinGetClass, FocusedWindowClass, % "ahk_id " . Hwnd
15.   Return (FocusedControlClass = CClass) and (FocusedWindowClass = WClass)
16. }

[ewemoa]

Perhaps a new topic is in order?

FWIW, the following is something that tries to work with a wider selection of controls:

  http://ewemoa.dcmemb...mp/CtrlBSDelHack.exe

SHA1: 7e808d15300c9bfb40e6b66d09f0893a112a6432

[ewemoa]

lanux128, I am not finding the hack to work in the following situation.

Req: Ctrl+backspace to delete from cursor position

Without the hack running, Control+LeftArrow at the end of the path field will move the cursor to the beginning of the field.

Before:
  C:\WINDOWS\System32|

After:
  |C:\WINDOWS\System32

where | shows the cursor position.

Contrast this with Windows Explorer's address field where the result is that the cursor moves to the right of the last backslash.

Before:
  C:\WINDOWS\System32|

After:
  C:\WINDOWS\|System32

Without the hack running, do you happen to know some general keystrokes that would move the cursor to the right of the last backslash in the Extraction Wizard dialog?  More generally, moving the cursor to the first backslash to the left of the current cursor position

I'd rather not do things that involve copying the text, analyzing the content, and sending arrow keys to get this to work...

[lanux128]

i noticed this too on a installer dialog (can't remember if it was InstallShield or NSIS). they do not seem identify the backslash as a delimiter, unlike the way windows explorer does. i believe this is the default in most text editors and word processors. i'll let you know if i find out anything.