Our applications use browse lists extensively to assist with researching historical data. QBFTABLE was helpful when it was added, but we lamented that it didn't seem to let you click on a displayed row and go to it.

I ran across this in the 7.2 documentation the other day…

"Remarks Navigating through the resulting table will display the highlighted record data in the current window."

Is this feature functional, or could I possibly get it to function? That would sure make some users happy.

Perhaps I am just invoking it in the wrong way or something. With a browse list active, I am simply executing

Send_Event(@Window, "QBFTABLE")

when a button is clicked.

This builds and displays the popup, but clicking on a chosen row does nothing.

Is there something more to this that I should be doing to make the navigation feature work?

Thanks,

Jim

Jim,

If I just throw a button on my form and send the QBFTABLE event from it, it builds the Table window and then as I navigate through the table the records are displayed in my window.

If I use the QBF menu all seems fine also.

How are creating the active list?

What version of OI are currently using?

Sean

That sounds encouraging. It can work then.

The browse list is either built with the QBF itself, activated by a button, or passed as a list when the window is started and loaded into QBFLIST in the Create event.

This application is still at 7.2.0. That could be part of the problem, but I think I have tried this on 7.2.2 also with the same results. It is also possible it is being eaten by our promoted events somewhere.

Is there anything you can tell me about how the row number selected in the table is being passed back to the window that might help me trace things?

Thanks!

Is it returned in the return value settings of the Quick Event properties dialog for the button?

"Is it returned in the return value settings of the Quick Event properties dialog for the button?"

Oh, I wonder. I am not using quick events anywhere.

Sean, did you use a quick event for your little test, and if so, what did you do with the return value?

I see what is happening here, I'm just not sure why. The QBFTABLE window is displaying its browse position on the top of the MDI frame… … instead of sending it to the active window.

Using the debugger, at the point where QBFTABLE mode is invoked with Send_Event(@WINDOW,"QBFTABLE") , @Window contains the correct window name. The navigation results are going to the MDI frame though, regardless of whether I set up a new button with quick events or let my event code do it using the existing button.

Any ideas?

Jim,

In the MDIFrame change the QuickEvent to use @MDIACTIVE instead of @WINDOW.

In my test form, I didn't do a thing with the return value.

Sean

Sean,

The QBF buttons are all on the child forms. I don't have any quick events defined on the MDI frame. Should there be?

Thanks,

Jim

Jim,

I assumed that since you mentioned the events were running the mdiframe that you were using menus.

Sean

For whoever else runs into this someday…

After spending a little bit od quality time bonding with the debugger, I found this:

The form QBFTABLE had in its PARENT property the name of the MDI Frame, not the name of the active window that was passed to it in the Send_Event(@Window, "QBFTABLE") call. This is in 7.2.0, possibly it has been fixed.

Clicking a row generates a POSCHANGED event for the edittable on the form, also conveniently named QBFTABLE, same as the window, just to create possible confusion.

The row number is in the second parameter from the POSCHANGED event,

which I intercepted in one of the commuters handling promoted events. This got it working:

Special handling Case Window EQ "QBFTABLE" If Control EQ "QBFTABLE" And Event=POSCHANGED" Then Row=Param2 Frame=Get_Property(@Window, "PARENT") Parent=Get_Property(Frame, "MDIACTIVE") Set_Property(Parent, "QBFPOS", Row) End </QUOTE> —- === At 05 APR 2007 04:58PM Sean FitzSimons wrote: === <QUOTE>Jim, The bug is fixed in 8.0. Sean </QUOTE> View this thread on the Works forum...