The first column has number 1 according to status bar and 0 or 1 according to ruler depending on configuration setting Start ruler numbering at column 1. For search in column feature the column numbering starts always with 0 for first column. This explains why 29 must be entered to find a string beginning at column 30 according to status bar. The character in end column is not included anymore in search. Therefore 31 must be entered as end column to find a string in column 30/31 with column counting starting with 1 respectively 29/30 with column counting starting with 0.

Whether Find Next (F3) nor Find Prev (Ctrl+F3) are designed for search in columns. This special search option is not taken into account by those two commands. Well, it looks like it works partly for command Find Next, but this is not really by design.

What should work by design is activating search in column, unchecking option Close after find and using button Next to find a string in specified columns only.

But doing a reverse search using button Previous in Find window ignores also the limitation on specified columns. Well, reverse searches are always problematic as no search engine is designed for doing a reverse search. I need to further investigate this issue and report it to IDM support by email.

What works fine in UE for Windows v22.20.0.40 (and also v16.00.0.1040) is using the Perl regular expression engine for search in columns 30/31.

The search string to use is: (?<=^.{29})xy

(?<=...) ... a positive look-behind to verify if the string is really found in columns 30/31.

^.{29} ... there must be exactly 29 characters left to found string and those 29 characters must be found at beginning of a line.

xy ... is the string to find.

This Perl regular expression find works for

123456789 123 xy 89 12345678 xy 3456 xy
987654321 321 xy 98 87654321 xy 6543 xy
864297531 231 xy 45 75318642 xy 3654 xy

also with using the commands Find Next and Find Previous.

Of course this expression does not work with 1 or more horizontal tab characters existing between beginning of line and the string to find in the columns of interest as tab width currently configured for active file is not taken into account by the Perl regular expression engine. In this case it would be necessary to use Format - Tabs to Spaces or adapt the multiplier number in the search expression if the number of tabs is constant for all lines containing the string to find in column range of interest.

I investigated search in columns feature and found out that a reverse search in columns was indeed never part of design.

This can be seen by checking setting Show slim find dialog after start at Advanced - Configuration - Search - Miscellaneous, opening Find window, enabling In column, specifying a column range and clicking on button Next. In slim find dialog the button Find Previous is disabled indicating that a reverse search in columns is by design not possible.

Therefore my report to IDM support contains two suggestions:

1. Find feature is enhanced for supporting also a find in specified columns in reverse direction.
   
   In this case just the button Find Previous in slim find dialog does not need to be disabled anymore depending on In column option.
   
2. There is no enhancement made on find feature.
   
   In this case the button Previous in Find window should be always immediately disabled when In column is checked by user and enabled again if the user unchecks this option.
   
   And of course the button Previous should be also disabled on opening the Find window and In column is enabled from a previous search because of configuration setting Search in column is not enabled at Advanced - Configuration - Search - Auto Reset Settings.
   
   And it should be added on paragraph about option In column in help of UltraEdit on page Find command (Search menu) for example:
   
   Search in column is possible only in downwards direction.

It was indeed confusing for me too that specified end column is not included in column range as well as starting column numbering for search in column feature with 0 instead of 1 as displayed in status bar for first column.

But I think it is too late to change this now. There are perhaps already lots of macros and scripts using find in columns with the values required by current column range system. Therefore making a change here would cause incompatibilities with all those macros and scripts if not introducing additionally a new parameter name for a different column range system for find in columns and supporting both column range systems for macros and scripts.