>>>There should be trouble only if the vertical space is insufficient. If there's not enough space below, the menu should unfold upwards. Just tried this with this browser (waterfox in my case, but since menus are a system level GUI thing practically everywhere, you can try it with any other app): moved the window most of the way down, so that there were just a few pixels below the menu and toolbars, and opened the largest branch of the menu. It went upwards. So if the vertical size of the menu branch in case is larger than sysmetric(2) (or whatever the parameter), then... the menu system should be intelligent enough to draw scroll buttons on top and/or bottom of it. I hink I've even seen this in fox... but where, in FPD2.6?
>>
>>I see the same thing you see. The menu moves up when I moved the form down (to simulate the case of lack of space below). But the customer sent me a pict of his screen where it clearly shows the menu beginning at the bottom and not enough space to show the entire menu.
>>Strange.
>
>Exactly the reason I generally avoid putting everything in the menu, or if I must, split it into multiple columns. For really busy stuff, I rather used a switchboard form, or rather a launcher form, which just had groups of buttons, and launched other processes from it. For example, if your app has some six or seven reports, they can go into a menu. More than that, create a report launcher form and let the user pick from it - and there you have a listbox or whatever.
>
>Again, menus are system driven and most of the time you have very little control over their appearance and behavior. With forms, you're in charge.

You are very much correct. I should have thought about it before. I will start working on changing the pop-up menus with the form. I have never created what you call "borderless headerless scrollable form with wide buttons" but hopefully will learn quickly.
Thank you for your help!