Refresh Embedded Browse

[michaelwpayton]

I have read everything/tried everything I can find out here relating to refreshing an Embedded Browse.

- Form with "Parent" on top... Embedded Browse of "Children" below.
- Form Properties include a Filter on the "Child" table.
- Changing a drop-down, changes the value of a variable in the 'Child' Filter

How 'should' I cause the Embedded Browse to refresh? I assume my drop-down's "Change" Event should refresh, resync, whatever... but I have tried everything... with very inconsistent results. I am not trashing Alpha, but without any changes to my code or the data... I seem to see, from time to time, execution by execution, minute by minute... changes in behavior of the application.

What I am looking for is how others develop Forms like this... that result in a stable, predictable application. This cannot be, should not be, this hard. I hope I am the idiot here... but I'm starting to believe that certain portions of Alpha are just plain "flacky." That's fine... even understandble in a product this robust... but I need a "best practice" for this very typical application.

Thanks,

[Tom Cone Jr]

Re: Refresh Embedded Browse

Mike, how about posting a sample?

[michaelwpayton]

Re: Refresh Embedded Browse

Thanks for the reply.

I'll work on that... but it's not as easy as you may think... long boring story.

But, in the mean time... do you/does anyone have any suggestions as to what works/doesn't? There just are not that many moving parts here... you know?

How 'should' one cause Alpha to refresh (resync, whatever) an Embedded Browse when the Filter associated with it is modified?

Sorry, just frustrated here...

I'll put together something/a sample and upload as soon as I can.

Thanks,

[Tom Cone Jr]

Re: Refresh Embedded Browse

The sequence I would expect would be something like this:

a) user changes desired filter
b) onChange runs a new query against the embedded browse object
c) onChange refreshes display of the browse object

Should not be terribly difficult, but changing the variable used in the filter expression defined initially in the properties of the form layout, alone, will probably not get it done.

[michaelwpayton]

Re: Refresh Embedded Browse

Tom,

According to Alpha's Help, there are a number of ways, methods, etc. to cause the engine to do what one would expect when the filter is changed. One of those mentions, from the Help, is below.

But... it certainly does not seem to work.

========================================
<OBJECT>.RESYNCH()

Syntax

<OBJECT>.RESYNCH()

Description

The <OBJECT>.RESYNCH() method applies to:

Browses (for <OBJECT> use either the <BROWSE> pointer or the name of the browse)

Forms (for <OBJECT> use either the <FORM> pointer, the name of the form, PARENTFORM, or TOPPARENT)

The <OBJECT>.RESYNCH() method does a new query, re-fetches all data for the form or browse, and then repaints it.
Supported By

Alpha Five Version 5 and Above

Limitations

Desktop applications only.

Example

This script is attached to a button on a form. It re-synchronizes the form with the data in the table and repaints all of the controls on the form, including any embedded browse controls.

Parentform.resynch()


This script refreshes an embedded browse named browse1. Note that an embedded browse must have focus before being updated.

browse1.activate()

browse1.resynch()
===============================================

[ChrisHawkes]

Re: Refresh Embedded Browse

Hi

I'm still using v8, and browses have always seemed flaky. What one procedure works for doesn't necessarily work for another, but whenever I've used a filter, the following seems to work best consistently.

[I]formname[/I]:[I]browsename[/I].Fetch_First()
[I]formname[/I]:[I]browsename[/I].Activate()
[I]formname[/I]:[I]browsename[/I].Resynch()

[Tom Cone Jr]

Re: Refresh Embedded Browse

Mike, I don't think the help file contemplated the use of a base level query. I think they were talking about a different situation. i.e. refreshing the display when an external process (another form for example) has changed the underlying data. Resynching will rerun the original query and thereby adjust the display for the changes that were made externally.

Here, you're doing something entirely different. You're trying to change the properties of the form layout itself, by manipulating the base filter expression in the layout. When you store the filter expression in the form properties you create a base level query. In my experience Resynch cannot change the base level query. You must create a new base level query, then refresh the display.

[michaelwpayton]

Re: Refresh Embedded Browse

Tom,

I guess... but the fact that "sometimes" it re-syncs (using the word in the English sense vs the method sense) and sometimes it doesn't, indicates that perhaps the engine doesn't quite know what it intends to do. That's the scary part.

[G Gabriel]

Re: Refresh Embedded Browse

You say:

I have read everything/tried everything I can find out here relating to refreshing an Embedded Browse.

I believe you did. You probably didn't read the repeated pledges I made time and again and every chance I had, so I will try it one more time:

Please DO NOT, NOT EVER,.. USE A FORM BASEQUERY.

No, it is not entirely your fault. You'd say: Alpha offers it then why no use it? And why doesn't it work?
Alpha offers it BUT you've got to understand what it does and how it works.
And why doesn't it work? It does, but if you don't quite know how it works you'd think it doesn't.

In a sense, you are trying a Harry Houdini stunt and it is not going your way. There is no getting out of that straight jacket or those shackles.

How so?
You have a form basequery.
That basequery has a filter that has a variable.
You want to be able when you change the value of that variable, to see the new child records that meet the new value.
Sounds simple.
It is. But not exactly.
Why?
Because you keep going back into that same straight jacket known as "basequery" as a final step. So, even though the variable changes and even though the filter changes, but right before Showtime, you pass through the same old basefilter that is part of the form design so all the changes in the variable and filter, amount to nothing when you finally go through that base filter.
Let's do it slow motion:
1-You load the form, the child records shown are compatible with the filter in the basequery
2-That filter is based on a variable
3-You change the variable somehow
4-Now you want by whatever maneuvers you employ to see child records that meet the new value
5-Not a chance. Because in the final step as form is refreshed, it will PASS THROUGH THAT BASE FILTER.
Unless you physically change the definition of that filter, you don't have a chance. I don't believe alpha provides that ability. I haven't looked and looking would be a major waste of time, as I have no intention of ever using a base filter.

Now I could be wrong and someone might have a way to make this work even with the base filter and this Harry Houdini metaphor is totally wacky, but personally I wouldn't even try. It's waste of time. I just think base filter is such a bad idea. The board is replete with threads that had to do with base filter. Search the board and you will see and you will also see that every time I sounded off the same message.

What is the alternative?
Take out that base filter.
Run a query on OnInit event and later at anytime you change the variable.

[enstorms]

Re: Refresh Embedded Browse

G., thanks for the explanation, (again). I finally am beginning to understand what you are saying concerning the base query. I'll begin to implement the suggestion.
Ernie

[Tom Cone Jr]

Re: Refresh Embedded Browse

G, changing the basequery for a form is not especially difficult.

Assume the existence of a form called "Form1", based on the Customer table in AlphaSports. Assume that the designer embeds this filter expression in the properties of the layout:

"Bill_State = 'MA'"

This will limit the display to customers in Massachusetts. To change this so that the form will be limited to customers in California, you'd do this...

Form1.BaseQueryRun("Bill_State = 'CA'","Lastname")

[Peter.Greulich]

Re: Refresh Embedded Browse

- Form Properties include a Filter on the "Child" table.
- Changing a drop-down, changes the value of a variable in the 'Child' Filter

Try dropping the form level filter and use code instead. As someone said, put this in the OnInit:

this:tables:child_table_name.filter_expression = "Your_Item=whatever"
this:tables:child_table_name.order_expression = ""
this:tables:child_table_name.query()

Then in the dropdown's OnChange event, put this:

parentform:tables:child_table_name.filter_expression = "Your_Item="+s_quote(vItem)
parentform:tables:child_table_name.order_expression = ""
parentform:tables:child_table_name.query()
parentform.resynch()
browse_name.refresh()   ''not sure you need this line

[michaelwpayton]

Re: Refresh Embedded Browse

Thanks everyone... we coded around it... I appreciate your counsel and patience.

[G Gabriel]

Re: Refresh Embedded Browse

G, changing the basequery for a form is not especially difficult.[/CODE]

Tom:
That might very well be. I just don't see the point of constraining the form with a basequery when you could run a query anytime you need it, when you need it.

[Tom Cone Jr]

Re: Refresh Embedded Browse

That might very well be.

Right. It is. :)

Using queries that are dynamic (not embedded in the structure of the layout) is much more flexible, and in the hands of an experienced developer is certainly the way to go. I suspect basequeries are available to assist the less experienced. Folks who can build a filter expression with the help of form design genies, but who are baffled or intimidated by the prospect of writing code to do the same thing. I rarely use basequeries myself, for example. I mentioned the <form>.basequeryrun() method only because it sounded as though you might have forgotten about it. The mention was not intended to suggest that manipulating basequeries is the preferable course in the typical case. In cases where the designer wants to let the user change the filter applicable to the form the use of basequeries is not the preferable course.

-- tom