Smartbrowse loses link to smartviewer

[Tarby777]

Hi all,

Apologies in advance for what is going to be a rather vague ADM2 question. I finally find myself working on some ADM2 code after 33 years as a Progress dev, and I have a bug to fix. I'm keen to find out if it's a common one with a known fix. Apparently this particular bug has been in the application for years, across multiple Progress versions. It is currently running 11.6.4.

I have a smartwindow with a smartviewer to maintain a single row in a parent table. A smartfolder in the window has several tabs, each one being for a separate child table. Each tab in the folder typically has a smartbrowser, smartviewer and update panel for that child table. The bug - which only seems to affect one tab - is that after switching to another tab and coming back to it, clicking a row in the browse no longer updates the viewer. You can click away to your heart's content on different rows in the browse - "value-changed" still fires and the row gets highlighted in the browse as you'd expect, but the viewer still shows the record that you were looking at before you switched to the other tab and came back. Users have a longstanding workaround, which is to hit 'add' in the problem panel, and then cancel the add. Whatever this does is enough to restore the link between the viewer and the browse.

The value-changed trigger on the browse contains only {src/adm2/brschnge.i}, which does only this:
RUN onValueChanged IN TARGET-PROCEDURE.

This normally causes RowDisplay to run in the browser, and DisplayFields to run in the viewer. When things go bad, these procedures are no longer invoked. It looks like onValueChanged lives in src/adm2/browser.p. Looking there, I see this:

{get BrowseHandle hBrowse}.
IF NOT VALID-HANDLE(hBrowse) THEN
RETURN NO-APPLY.

I think this is most likely where it is going belly-up... it has lost the handle to the browse so it gives up... displayFields & rowDisplay don't get called and the viewer isn't refreshed. Does this ring any bells?

TIA
Tarby

 

[peterjudge]

I finally find myself working on some ADM2 code after 33 years as a Progress dev, and I have a bug to fix.

Congrats? FWIW I have recently worked on ADM1 code , so I completely empathise.

Why would the BrowseHandle *not* be set though? Can you, in the value-changed trigger, {set BrowseHandle {&BROWSE} } (forgive the syntax, hopefully my point is clear)?

 

[Tarby777]

Can you, in the value-changed trigger, {set BrowseHandle {&BROWSE} } (forgive the syntax, hopefully my point is clear)?

Thanks Peter. Every day is a school day! I didn't know that I could use those get/set routines like that, in the way that the ADM2 code does. Checking the value of BrowseHandle and others has enabled me to get a little further along the road... I see now that the browse handle doesn't get lost when I switch tabs and come back, and it is still a VALID-HANDLE. Ditto for DataSource and NewRecord, which also come into play in OnValueChanged in browser.p.

Looking further into OnValueChanged, I see this:

IF DYNAMIC-FUNCTION("isOkToFetch":U IN TARGET-PROCEDURE, "VALUE-CHANGED":U) THEN
DO:
{get DataSource hDataSource}.
/* Traditionally the browser just used run dataAvailable from the events,
but this is now in a super-procedure and the sbo need to know the
target, so we subscribe the source temporarily. */
SUBSCRIBE PROCEDURE hDataSource TO 'DataAvailable':U IN TARGET-PROCEDURE.
PUBLISH 'dataAvailable':U FROM TARGET-PROCEDURE("DIFFERENT":U).
UNSUBSCRIBE PROCEDURE hDataSource TO 'DataAvailable':U IN TARGET-PROCEDURE.
END.

I checked isOkToFetch in my value-changed trigger. When everything is working well it returns true, but returns false when the browse isn't updating the viewer. Looks like that's my problem. It sounds similar to this problem, but the advice here goes over my head:

Lost data link to viewer - OpenEdge Development - Forum - Progress Community Archive

Looking for an answer to your question - Lost data link to viewer? Check the threads in OpenEdge Development - Forum or navigate to the new Progress Community.

community-archive.progress.com

TIA
Tarby

 

[PatrickTingen]

Can you use the debugger to step inside 'isOkToFetch'? You might be able to find why it says 'no'

 

[Tarby777]

All good now... I think it was more a coding problem than anything else. I made the smart window .w re-open the browser query on the problem tab whenever the user moves to it from one of the others. It was already doing that for the other tabs...