I am having problems with the Variables subgroup in my Function List. Seems there is an incremental offset, +1 for each variable found.

e.g.
My Function List is hierarchical:

• FUNCTIONS
  |--getInstance
  |------PARAMETERS
  |----------$uri = 'SERVER'
  |------VARIABLES
  |----------$var1 = 's' <--- double-clicking here takes me 1 line above $var1
  |----------$var2 = 't' <--- double-clicking here takes me 2 lines above $var2
  
  VARIABLES
  |--$var1 = 's' <--- double-clicking here takes me to $var1
  |--$var2 = 't' <--- double-clicking here takes me to $var2

Is anyone else having this problem? I've seen some posts where Mofi suspects memory problems with the Function Lists -- but I haven't seen this problem mentioned in the forums (did I miss it?)

Group definitions:

I have sent to IDM in the past severals emails regarding problems with hierarchical function list feature including the one you see here too:

On 18th July 2010 - Line number problem if % used in subgroup function string regexp

According to my tests which I ran from time to time on the problems I reported, this issue as well as the others hierarchical function list problems can be still reproduced by me and are therefore not fixed.

To be honest I don't have seen any improvements on the hierarchical function list feature in the last 2 years. That is very unsatisfactory. But additionally to reporting problems I see with hierarchical function list feature, I can't do anything else than asking other users reporting the issues they see. IDM fixes the reported issues based on a priority system. Highest priority and always immediately fixed are problems resulting in a crash of UltraEdit. Next, problems are fixed quickly resulting in corrupting or damaging edited text. All other issues are fixed according to number of users reporting an issue. That means the more users report problems on hierarchical function list feature the higher will be the priority for IDM to fix them.

I use for myself the hierarchical function list feature only for C/C++ where it works fine (for some unknown reason) and for HTML files. But for HTML files I use this feature to get in function list view simply 4 top level lists: external hypertext references, image sources, anchor names and page internal hypertext references. So the function list is not really hierarchical as there are no subgroups for HTML files, just up to 4 top level lists.

All the problems I saw and reported where detected on hierarchical function lists created for other users for other file types like PHP, Monkey, and some other exotic files.

Please pack the PHP file and your php.uew with ZIP or RAR and send the archive file together with some explanations what is not working correct to IDM support by email. You can mention that Mofi has reported a similar issue too and is still waiting for a fix on this issue as well as other reported hierarchical function list problems too.

BTW: I copied the PHP snippet into a new ASCII file with DOS line terminators and saved the file as Test.php. Next I copied your function string expressions into php.uew and saved this file too. Then I opened the function list view for Test.php and see the same listes as you. But caret is set wrong only on double clicking on $var2 = 't' in variables list of function getInstance where caret is set to the line above the line containing $var2 = 't';

This is unfortunately what I have seen also in my tests and what I reported also to IDM. The problem depends on file contents. I have once played several hours with such a wrong line on double click issue to find out what exactly is the reason why the function list works fine for one file but has this problem on another file. I had to give up to find the reason as the behavior was permanently changing with changing the contents of the files. That's the reason why I think there are memory respectively array problems.

---

Some other notes on your UltraEdit regular expressions:

The UltraEdit regular expression engine does not support hexadecimal notations. All supported special characters by UE regexp engine are listed on the help pages Find command (special characters table) and Regular Expressions (Legacy) (upper table). The regular expression builder lists for Find and Replace search string in Find/Replace dialog are complete for the UE and the Unix engines. Just for the Perl regexp engine the regular expression builder lists are just a short summary as listing all options of the Perl regexp engine in a simple list is impossible due to the huge amount of options and context dependent expressions.

You have to use ANSI character definition -ÿ instead of \x7f-\xff in the expressions.

And the regular expression search for function string is ALWAYS executed with ignoring case. Therefore [a-zA-Z] is equal [A-Z] and equal [a-z]. Using [a-zA-Z] in function string regular expressions is not really wrong, but [a-z] matches the same set of characters in an UltraEdit function string regular expression and makes the expression 3 characters shorter.

However, even with making these modifications and use the expressions as posted below, the wrong behavior is not disappearing.

Thanks for your feedback Mofi - much appreciated.

I am preparing a list for IDM with how to recreate this and other problems I discovered during my evaluation of UES.

May you have a peaceful weekend ; )

Sam