smartFilter issue in child window taking foreign fields from

We have resolved many issues with filters in windows and also issues when running child windows with data links standalone, but I cannot remember any issues when starting child containers with a filter window the way you describe. Your code is very old (I'm sure I've hinted at this before) and there are also a lot of ways to set this up, so I could very well miss something. If you give us the stack trace and also explain what the code is doing when it errors someone might be able to help.

Thanks Havard,

I apologize for not having upgraded our version yet. We should be doing that later this year. In the meantime I appreciate your assistance with my issues.

The error message "ENTRY 2 is outside the range of list (560)" occurs just once when the child widow is being launched via a button on the parent window before the window is visible. The window appears to function normally after that. If I remove the filter window from the child container there is no error produced. Is the stack trace you are referring to the ProSpy log or something else, and would you want me to post that here?

thanks again,

Paul

You can get the stacktrace from an error message if you use the -debugalert startup parameter. it can also be set in code using session:debug-alert. ( It is almost mandatory in a development environment). This option will make all errror messages appear with a Help button that you can press to get the stacktrace. You can also start the debugger from the dialog that pops up.

You can post the stacktrace, but it is not certain that this provides enough info to understand what the problem is.

Thanks.

see attached.

Sorry, I sent that out rather quickly before I had a chance to really look at it and am anticipating that you may point out that the procedure is throwing the error in the custom filter.p override. I have removed that override and am still getting the same error. See the new stack trace attached.

thanks,

Paul

I took a quick look in filter dataAvailable (the code is unchanged since Nov 2000, so it is likely the same code you have) and it is hard to guess what the problem is. Suspect number one is the ForeignValues. You could get this error if you have a multi-component foreign key and the ForeignValues does not have an entry for each key separated by chr(1). Too many entries in the ForeignFields could also cause the same problem. It could also be a completely unrelated problem with DisplayedFields and fieldHandles not being in synch.

It could also be a timing issue. The filter  coud receive dataAvailable before the pass-thru link is realized, but that seems unlikely, since most of the code only is executed when certain properties have data. This seems to be the code that displays the ForeignValue(s) in the filter, so some of it seems to work, which would not be the case with an unresolved pass-thrru link. .

The code is not supposed to fire if the filter has no filterTarget, so your filter-link removal seems to have been unsuccessful.

I see from the debugger that the cFieldHandles variable has no value at the time of the error. Both the cForeignFields and cForeignValues variables seem to be correct. Could this indicate a timing issue as you suggest?

Just to clarify, I haven't removed any of the filter links in my code except temporarily for testing whether the source of the error is associated with the filter. Removing the filter link from the child maintenance window to the filter window results in other errors which I suspect are due to the filter link between the dynfilter and its window.

In the initializeObject override on my child maintenance module (which has the child filter window) I have included the following code to set the foreign fields only if a data source is available. It also disables the filter button on the toolbar but does not remove the filter links:

    DEFINE VARIABLE hDataSource AS HANDLE NO-UNDO.
    {get dataSource hDataSource}.
    IF VALID-HANDLE(hDataSource) THEN DO:
      DYNAMIC-FUNCTION('setForeignFields':U IN h_daggregate, INPUT "aggregate.siteNum,siteNum,aggregate.siteCode,siteCode,aggregate.aggNumber,aggNumber").
      DYNAMIC-FUNCTION ('ModifyDisabledActions':U IN h_dynToolBar, 'ADD', 'Add,Copy,Delete,Filter').
      PUBLISH "disableXmendButtons" FROM THIS-PROCEDURE.
    END.

Do I need to remove the filter link between the dynfilter and its window and the filter link between the sdo and the filter window?

thanks,

Paul

pauldownie wrote:
I see from the debugger that the cFieldHandles variable has no value at the time of the error. Both the cForeignFields and cForeignValues variables seem to be correct. Could this indicate a timing issue as you suggest?

If cDisplayedField has data and cFieldHandles is empty then it could be a timing issue, but from looking at the code I would actually think you'd get an invalid widget-handle in that case. (I may be wrong).

If you use the debugger you should be able to tell exactly where the problem is.

Do I need to remove the filter link between the dynfilter and its window and the filter link between the sdo and the filter window?

I assume this would eliminate the problem, but I suspect there are simpler ways. One thing that puzzles me is that you said the that the filter is showing the foreign values. This indicates that this code actually works. Maybe it is called more than once (for the same parent)? Maybe you can add some sanity check for this particular case and avoid the ENTRY call if the list that fails does not have any entries.

Thanks Havard. Your suggestion to put a check on the cFieldHandles list seems to have worked. I am not sure if this is the solution or information to be used to track down the real problem. As you suggest, it must be firing more than once for it be working after the error. Should I be satisfied and move on or do you think there is some other problem to be addressed?

Paul

The dataAvailable message is published each time the parent changes, so you should ideally make sure that both messages are for the same parent, or really that the last is for the correct parent. On the other hand the only thing that happens here is display of foreign key values to the filter UI. Given that you seem to have disabled the filter action from the toolbar, you do not really care.

Trying to resolve the timing issue and/or the extra message would likely be both complicated and risky.