Showing results for 
Search instead for 
Do you mean 
Community Home Request Access Read Blogs Share Your Ideas Search Community View My Settings
Reply
Tuned Listener
Posts: 4
Registered: ‎07-19-2009

txtDataBoundChange in Opportunity:Products

Hello @all, I have a question about Sub txtDataBoundChange in OpportunitySmiley Tongueroducts. Why the event fires twice? Where can I catch it? Or how can I run on a tab at the OnChange event a function only once? Many Thx for Help Greatings Martin
Gold Super Contributor
Posts: 3,087
Registered: ‎03-19-2009

Re: txtDataBoundChange in Opportunity:Products

Oh yes.. that is the "hidden" bound control tied to the OPPORTUNIITY.OPPORTUNITYID.

 

It's probably happening for one of several possible reasons:

   A - Multiple refreshes of the Opportunity Products tab that you probably have no way of controlling

   B - It's in a container control that is in a form... (however, that is not the case in this situation).

 

What's the reason for not allowing it to fire more than once?

 

FYI - Due to the design/implementation of the event model in the SalesLogix exe... this (multiple "firings" are happening ALL over the place in the client.. and there is basically nothing you can do to prevent it. (Not saying it is right ;-)...

 

We BP's have been living with and designing/implementing around this issue ever since vers 2.x of SalesLogix.

 

--
RJ Ledger - rjledger@rjlSystems.net +1 603.369.3047 x101

".. Innovators in Mobility - Experts in Workflow Automation..."
http://www.rjlSystems.net - blog: www.rjlSystems.net/blog.html
Tuned Listener
Posts: 4
Registered: ‎07-19-2009

Re: txtDataBoundChange in Opportunity:Products

thx...
reason is performance...there are some calculations
designing/implementing around this issue is my job now...but how???????
Highlighted
Silver Contributor
Posts: 835
Registered: ‎03-24-2009

Re: txtDataBoundChange in Opportunity:Products

[ Edited ]

Having gone through this exercise on my last project, although RJL knows what he's talking about you most definitely can eliminate ALL of the multiple refreshes of forms and datagrids.....from every SLX form.

 

There are three reason for the multiple refreshes:

 

1. bad documentation on what every SLX function does and how it affects forms/routines/calls....so that you program around what you think you know instead of what is actually occurring. Ask 100 SLX developers what Application.BasicFunctions.ShowViewForRecord does and you might get 1 answer that is even close to correct (specifically it fires a Refreshmainview after returning to the calling form from the 'showed' form....which automagically fires off an AXFormChange on the form you are calling ShowViewForRecord from which of course refreshes all of your datagrids....)

 

2. Bad Grid coding practices from a basically tiny/small documented change to the way grids are refreshed in 7.2000. We all did
grid.sql.text = 'whatever'
grid.refresh (that's TWO refreshes)

or

grid.bindid = 'accountID'

grid.refresh (that's THREE refreshes (add one for the :BINDID clause in the SQL property of the grid))

Back in the day....not realizing that in 7.20 this meant MULTIPLE firings of grid refreshes. The Rules changed in 7.20 and I still see:

set grid.recordset = myrecordset

grid.refresh (that's TWO refreshes)

 

that's a round trip to the SERVER through User Team security and Field Level Security every single refresh.....10 items in a grid no big whoop....500 items in a grid =death.

 

3.  Bad Architecture of the form and scripts.....redundant unnecessary calls... Insert Opportunity has two calls to SaveOpportunity from an A) OK button and B) an AXFormCloseQuery event handler that is triggered by......the OK Button.

 

We've all bitched about the Opportunity Product form and it's use of a zillion recordsets and a zillion routines per grid....it's a tough can of worms that actually implements a controllable Cancel transaction/batch ability for users.....something ALL of our forms should do if at all possible.

 

You need to make the Opportunity Product SubSystem faster and more efficient?

 

No problem.

 

In your dev environment, put application.debug.writelines at the beginning and end of every routine and where it's called...figure out the redundancies and then eliminate them. Don't refresh when you don't have to, don't refreshmainview when you don't have to, don't triple refresh datagrids.

Run SLX Profile.exe always....and every time you see a grid being fetched multiple times remove the redundancy.....

 

once you get those cleaned up....here's a few more hints.

1. Use a Native SQL connection to fetch data for 'Everyone'...especially for read only searches and data grids. 10 times faster.

 

2. although grid.sortable should always be checked to ensure proper mulipage selections by the user, their is a nasty way to stop users from SERVER SIDE sorting that my boss figured out on the last project. Why SLX doesn't use Client Side Grid recordset Sort's is beyond me.....the data is in front of your eye's, exportable to Excel, etc..... i.e. it is in memory.....so sort it on the client side in memory!

 

3. We don't allow inline grid editing......

 

4. we rewrite Opportunity (don't like the HTML stuff), Opportunity Products, AddEdit Address, Products.....and make the code faster quicker and able to leap tall buildings in a single bounce.

 

5. only refresh grids ONCE and when you need to.....

 

 

 

 

 

RJ Samp