I can't say I have a really tight grip on your UI/data dependencies but one thing to be aware of with grids is they are very fragile if you requery the underlying data source after the object is instantiated. Over the years, when I've had the need to do really fun stuff with grids, I've ended up writing methods to set the datasource and rebuild the grid in code. Any time I may have saved myself by using the GUI to create the grid ultimately get sucked into debugging the damn thing. That doesn't mean I won't start with the GUI but once I have the grid the way I want it, turning that construction into code saves a lot of future effort.
If you want different behavior (i.e. wake up/go to sleep) based on the checkbox state then the interactivechange event is a good place to check that state. I would have some container level method (probably the form as opposed to the grid itself) that I would call and its responsibility would be to handle the enabling and disabling of other contained controls. By using a form level method, you can even get into some bindevents fun and not have to put a single line of code in the interactive change method of all those checkboxes. Sorry, I realize this is all a bit abstract but what you want to do seems to be fairly complex so it's really hard to offer more concrete suggestions. I picked up a lot of good info for making better grids from various Hentzenwerke books as well as devcon white papers on the subject. -- rk -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Joe Yoder Sent: Wednesday, June 04, 2014 5:14 PM To: [email protected] Subject: Re: How to trigger an update in a grid The app is very basic as I have little experience with the design environment. I don't think I'm doing buffering or transactions but if one of those is a default when one adds a grid to a form I might be. There is a free table, Inputs, which is the RecordSource (RecordSourceType 1) for the grid. Inputs stores information about time based data stored in a second free table, Detail. The function of the app is to allow the selection of one or more sets of time based data for reporting or plotting. The AdjRange procedure that gets called from the grid checkbox.valid event determines the range via "SELECT Min(BegStamp), MAX(EndStamp) FROM Inputs WHERE selected..." If the results are null the routine disables the elements on the form that only make sense when something is selected. When the results are not null the values are written to the form Report range variables which are used as the earliest and latest calendar time that can be selected for output. The AdjRange procedure does not make any changes to the Inputs table at this time. In the future I want to have the system automatically allow only data that shares time stamps to be selected. This will probably involve adding a filter. I initially was writing the scan results to a cursor. I got suspicious that maybe VFP was making invalid assumptions and reusing the results of a previous scan. I changed to writing to an array and things seem to be working better. Typical sequence: - Nothing is selected in the grid and the controls disabled - Clicking on a grid selection checkbox results in the controls come alive with the correct data - Clicking the same checkbox again and everything goes to sleep again - Clicking another checkbox - the record is selected but the controls stay sleeping - Clicking yet another checkbox results in the controls waking up - etc etc etc I tried adding a wait window before doing the scan thinking that a manual delay may give the system time to write to the table. This did not make a difference. At this point I'm thinking to try a non SQL scan to see if that solves the problem. I hope this all makes sense. Thanks, Joe On Wed, Jun 4, 2014 at 4:01 PM, Dan Covill <[email protected]> wrote: > Joe, > How are you 'updating' the table, via buffering or a transaction? > IOW, seems like the update is delayed somehow, so it wipes out > whatever your method did. > I don't do buffering or transactions, but one idea that occurs to me > is to set a form.property .T. when the column changes, and have the > update call the adjustment if the property is set.Are the values the > proc adjusts fields in the table? Does the update overwrite them? > Dan > > > Date: Wed, 4 Jun 2014 13:26:39 -0400 > > Subject: How to trigger an update in a grid > > From: [email protected] > > To: [email protected] > > > > Scenario: > > > > - A table with a logical column for selected rows > > - A grid with a table as the ControlSource > > - The grid has a checkbox for the selected column > > - Any change in the selected column needs to call a procedure > > that > scans > > the table for selected records and adjusts values and controls > > based > on > > what it finds > > > > I have everything working except the automatic triggering of the > procedure. > > I have tried it in the Click, InteractiveChange, and Valid events > > of the checkbox on the grid. The procedure runs but it seems to do > > so before > the > > table has been updated. > > > > How can I have the procedure run after the table has been updated? > Another > > approach? > > > > Ultimately I need to expand the update routine to change the > > criteria of the records that display in the grid. I was expecting > > to do this by changing the setting of a filter but I could change > > over to using a > cursor > > and create a new one each time there is a change in the selected items. > > Does this sound feasible in a grid or should I change to a > > different approach? > > > > Thanks in advance, > > > > Joe > > > > > > --- StripMime Report -- processed MIME parts --- > > multipart/alternative > > text/plain (text body -- kept) > > text/html > > --- > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/DF1EEF11E586A64FB54A97F22A8BD044239A77A3E3@ACKBWDDQH1.artfact.local ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
