>>>>>I am sure that the table-based approach would work. But, at this point, I do not want to change the menu in the application.
>>>>
>>>>You'd have to have a table of all reports and a table of users' short lists, so some way to pick from the big table and add to a personal list is needed, and a way to run any report from it... Sounds like a job for a report launcher form, with just a big listbox and a few buttons (add, remove, run).
>>>
>>>As I read Dmitry, he likes to stuck with a menu approach.
>>>
>>>I think he needs something to manage the reports - i.o.w. a form - and I would use this as a launcher as well. But users are used to interfaces, and we are not M$ changing the UI on every snow flake.
>>>
>>>Possibly he can try a two way approach - create the manage form, later add the launcher capability while creating the menu and later remove the menu.
>>
>>Thank you, both, for your suggestions. I will consider everything.
>

Me, from a user POV, would vomit if a non-file menu behaves like that. I have a visual orientation and expect an entry on a certain location. If I alter this location, well it's static until next intended change.

A MRU for files like in an editor is fine so far, since the file is the data.
>I think you should combine Dragan & Al:
>first make it EASY for each user to identify / find specific report
>- description table based in a grid,
>- perhaps 2nd window or description field form
>add Search option in Reports Menu
>Build MRU Menu via tables
>allow deletion in MRU Menu
>
>my 0.002 €
>thomas