It's quite a while since I played with menus the last time, but I think you must use the result of GETBAR() in DEFINE BAR and ON SELECTION BAR, not lnBar.

Vlad

>One small bug was bugging me since 2 years. It only happened a few times during development during that time. I just found the reason but I can't find a solution for it.
>
>This is related to my Window menu which is dynamic in order to reflect the actual forms on the screen. So, new bar are being added and removed frequently.
>
>At startup the menu is empty.
>
>1. I add item 1 which is defined as Bar 1
>2. I add item 2 which is defined as Bar 2
>3. I add item 3 which is defined as Bar 3
>
>4. I remove item 2, so the menu looks like this:
>item 1
>item 3
>
>5. I add a new item, so the menu looks like this:
>item 1
>item 3
>item 4
>
>6. Now, I have a process which need to update the prompt on item 4. So, I have a code which goes like this to find the prompt and to define it again in order to overwrite the current prompt:
>
>FOR lnBar=CNTBAR('gcWindow') TO 1 STEP -1
> IF PRMBAR('gcWindow',GETBAR('gcWindow',lnBar))==ThisForm.Caption
> DEFINE BAR lnBar OF gcWindow PROMPT 'My new caption'
> lcFormName=ThisForm.Name
> ON SELECTION BAR lnBar OF gcWindow ACTIVATE Window &lcFormName
> EXIT
> ENDIF
>NEXT
>
>The condition will be valid when lnBar=3, because item 4 is the one that I need to replace. So, as you see, I now DEFINE BAR lnBar in order to overwrite item 4. But, instead of replacing item 4, it is replacing item 3.
>
>The problem is the GETBAR() second parameter representing our visual view of the menu which is ok by the use of lnBar variable. But, the DEFINE BAR function keep using the initial position of the item. So, this is why the wrong item is replaced at this time. What can we use in order to use GETBAR() and DEFINE BAR so they will both use the visual position of the item in the menu?