AfterRowColChange not working

[Scott24x7]

Hi All,
I just discovered that AfterRowColChange does not respond to programmatic reposition, only manual. I've got a set of record navigation buttons that moves the row highlight in the grid, but it doesn't then fire the afterrowcolchange event, which I need to reposition other relationship grids as well... There is some odd mention in help about ActiveCell, but I couldn't get that to have an impact without causing some other unwanted behavior. Does anyone have a "trick" for getting the event to fire?
Many thanks.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Your relation settings and record positionings should not depend on such events, but be done in Refresh events.

I recommended working with Dynamic-Properties in thread184-1755026 because AfterRowColChange only happens in interactive changes and also only, if the grid has focus after the change (that event is not run, when the grid has focus and you click a control outside of the grid).

BeforeRowColChange and AfterRowColChange are grid events, not alias events, and they even don't run coupled. If smething outside the grid has focus, the first time you click into the grid you have grid.When, grid.AfterRowColChange, and when and gotfocus of a column's control (the order might vary and control events only happen, if the grid and its column controls are not disabled). When the grid or somethin in it has focus, the first time you click outside of the grid, only the BeforeRowColChange happens and Grid.Valid.

So the RowColChange events only help in case you want to react to grid usage, there are no events whatsoever reacting to RECNO() changes of a certain area. Therefore navigational controls also of the ffc navbar classes work with form.Refresh to have a cascading event every control might react, most important the native behaviour already refreshes control display without any further user code.

On the other side_ Relations are working properly always, the don't depend on any triggering, display of changes, eg moving a parent, which should cause other child data to displa, that's only a refresh problem, no more, no less.

Bye, Olaf.

 

[Mike Lewis]

I wonder if setting up an Assign event for ActiveRow and ActiveColumn would solve this problem. I haven't tried it myself, but it might be worth a quick experiment.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

Hi Olaf,
Actually, it was on your recommendation before I ditched all the persistent relationships. The grids are all built by SQL statements, and create a cursor.
Ironically, the issue is when the forms navigation buttons get pressed to change the record (I've built a routine to control both the Active DBF and the grid so that they stay synchronized). But that main grid needs it's AfterRowColChange (Which has at This.Click() event call in it). I was hoping that would work on it's own. But then I read when it wasn't working that it's only interactive change (as you mention) and not programmatic... annoying that they have an interactive and a programmatic change on other controls but not this one. (Lately, the more I get into grids the more I hate them... I was hoping to make some changes in my subclass of the grid, only to find that you can only replace the existing objects with a .PRG...)
So to your point Mike, I'm not savvy enough to know how to implement that? Would the button need to call it (because if that's the case, I might as well trigger the "click" event from the nav buttons, but that just seems messy).


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Yes, I don't recommend relations. I remember the opposite extreme situation you were in not seeing why relations cause what automatic record positioning, maybe a circular reference, maybe wrong usage of the relation or a bad index, did we found out? But when you use it, you shouldn't also need to do any action on your own.

If you don't use them, these grid events are only one ingredient. Mostly you'll pull data in activation events, eg a grid on a page of a pagefarame pulls its data at page.activate, don't push in the child data when the parent grid row changes, query data or position just in time, otherwise you pull a lot of data never even in view.

For all controls on the same page or current visible form part, a refresh should do it, or if you want to use AfterRowColChange, then don't allow any other navagation in records but with the grid. The navbar buttons are not needed, if you can scroll a grid, are they? They are outdated UI anyway. If you insist on them, centralize your routines to query dependent data and call it from both AfterRowColChange and from navbar clicks, a general way to decouple things.

Bye, Olaf.

 

[Scott24x7]

Olaf,
I did get the persistent relationships to work, but decided your earlier advice about not using them was better from a control perspective. So I did implement that, and no more relationships exist (though I do still use the DE for setting up tables used in the form, and for establishing initial index clauses).
All the navigation as you mention in the grids works fine. Click and AfterRowColChange all make that work fine. Navigation buttons are still there... are they needed? Maybe not. I was only worried about users that rely on them.
Probably everyone will cringe at this, but the grids I have largely setup to populate from their own Refresh clauses. So on the up side, a form refresh refreshes all the grids, which is where I set up the dynamicbackcolor after the grid data changes. For that part it all works great.
Maybe I will consider, as you say, dropping the next/prior top/bottom buttons. It's hard to "break with" that old method...

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Well, you can stay with a navbar, you just have to consider one thing: Removing automatic record positioning any place any parent record pointer can be influenced is a candidate for acting on child data. That's the price you pay. So you can call AfterRowColChange from fisrt/prev/next/last buttons, but rather add a method to the form, which is called from anywhere chaging the record pointer.

What you gain may be not doing anything until child data is really shown, lazy loading is the buzz word here.

User habits are one thing, but the best interface for longer lists is a search/filter anyway, ideally autocompletion/incremental search.

Last not least as said earlier in thread184-1755320 with my rant about customer wishes about forms at 23 Sep 15 11:36. It's your decision, but in the end smaller simpler forms with only parent or child data can do two things for you as developer and for users:

1. You only need to query data at form init for whatever parent ID - even the rrot form might not list all data, but say last month data.
2. Users can look at child data in child forms in parallel for two parent records.

Overall you don't need to synch this with parent repositioning. If another parent is of interest the user simply picks it and creates a third child form, the preexeisting neither need to update nor vanish. So you have the added benefit of seeing child data of different parents side by side. While this MDI interface may clutter the screen with separate forms, using docking capabilities (eg extended docking intelligence may merge data of two child forms instead of adding a tab) and letting users store preferences and favorites you overall gain a more dynamic composition of data than the massive all-in-one forms, which compare to another no go in OOP: God classes. Same rules as for OOP apply to forms and I encourage going against customer wishes for their own good. Software is not hardware, an application is not a car where everything is available to you at once, in software you can focus on the current context and zoom in and pan out of things important at some moment, not literally in the sense of the camera terms. Users not getting this should learn instead of software being customized to the users mindset. There's too much "seeing is believing" driven UI with users wanting to see all data, for example.

Bye, Olaf.