Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
the chicken or the egg?
I could test this myself but I'm being a little bit lazy as well as fishing for any other thoughts or ideas.
So, which event comes first the 'poschanging' or the 'afterupdate'. I am thinking logically it would probably be the afterupdate before the poschanging but I'm kind of hoping that's not the case.
I currently use the poschanging event for data validation and just set the cancel property if the validation fails. Works perfectly.
However, I was just thinking about simulating data binding by having a hidden databound OI table and populating that as the srp edittable changes. The afterupdate event seemed the perfect place to implement that concept. As the user commits their change to the cell, the afterupdate event fires passing the new contents to the commuter and I simply have to populate the corresponding cell in the OI table. Conceptually, it works great unless...
The poschanging event fires afterwards and the contents of the cell are found to be invalid, yet the OI cell has been updated already.
The other potential setback is if you change a cell programmatically, the afterupdate event doesn't appear to fire. I've provided the users the ability to copy cells, duplicate rows and the like but when I copy a row and insert it or set the celltext the OI table would not change because the user hasn't changed the cell contents directly. In theory I guess I could loop through the new cells or rows and use the fireevent method to force the afterupdate logic but that seems like a bit too much of an overhead for what is essentially generic promoted event logic.
So, any answers to the first question and/or any suggestions for a better approach?
Thanks
So, which event comes first the 'poschanging' or the 'afterupdate'. I am thinking logically it would probably be the afterupdate before the poschanging but I'm kind of hoping that's not the case.
I currently use the poschanging event for data validation and just set the cancel property if the validation fails. Works perfectly.
However, I was just thinking about simulating data binding by having a hidden databound OI table and populating that as the srp edittable changes. The afterupdate event seemed the perfect place to implement that concept. As the user commits their change to the cell, the afterupdate event fires passing the new contents to the commuter and I simply have to populate the corresponding cell in the OI table. Conceptually, it works great unless...
The poschanging event fires afterwards and the contents of the cell are found to be invalid, yet the OI cell has been updated already.
The other potential setback is if you change a cell programmatically, the afterupdate event doesn't appear to fire. I've provided the users the ability to copy cells, duplicate rows and the like but when I copy a row and insert it or set the celltext the OI table would not change because the user hasn't changed the cell contents directly. In theory I guess I could loop through the new cells or rows and use the fireevent method to force the afterupdate logic but that seems like a bit too much of an overhead for what is essentially generic promoted event logic.
So, any answers to the first question and/or any suggestions for a better approach?
Thanks
Comments
The chicken has always come before the egg. The order of events is as follows:
This assumes you have the events qualified as synchronous. Your best bet is to manage validation in the BeforeUpdate event handler and conversion in the AfterUpdate event handler. If you want to support default logic for your cells then this is best done in the PosChanged event handler.
The PosChanging event handler is best used to control the movement of the cell position based on other circumstances that are more oriented toward the business logic. For instance, maybe you want to block the movement into the next column based on data that was just entered in the current cell. The problem with handling validation in the PosChanging event handler is that the data is already in the cell, even if you implement the Cancel property. Now, you might be doing something to clear this data out, but this is why the BeforeUpdate event handler is better. If you cancel the event then the data is not yet committed to the properties that you would normally use to get the content of the EditTable control.
Using the poschanging for validation we don't actually clear the data out but the user is essentially confined to the cell until such time as they enter something valid or clear it out. This has worked to date and was so much better than the multitude of issues I previously had with OI tables and the poschanged event that I just never really looked any further. It was so exciting that I could validate something before I changed cells and not end up in an endless loop because both cells were invalid. :-/
I could move my poschanging logic to the beforeupdate event without too much difficulty and then the afterupdate approach would work. I try and stay away from the poschanged event just because it has that 'closing the gate after the horse has bolted' kind of feel about it.
So that leaves me with just the question about what to do when the cells are populated programmatically. Are any events triggered when you do this? For example, if I use the OLE.CellText property to populate a cell will any events relating to that cell fire that I could subsequently catch in my commuter?
Does your PosChanging logic work if the user immediately leaves the SRP EditTable or if the user does something to commit the data in the form (e.g., executes the WRITE event or executes the CLICK event of an OK button )?
Also, I agree with your concern over using of the PosChanged event. However, I want to make it clear that my recommendation to use the PosChanged event for default logic is not a "closing the gate after the horse has bolted" scenario. The PosChanged event for an EditTable cell is the same as the GOTFOCUS event for an edit line control. Both fire after being navigated into.
With regard to programmatic population of the SRP EditTable, you have to manage the event handler yourself.
Unfortunately the beforeupdate is not quite working for me as yet. The validation process I'm sure would be fine but I have some promoted event logic that occurs before that and it doesn't quite work at this point in the chain. Perhaps you can point me in the right direction for the appropriate properties to use?
What if I want to programattically change the contents of the cell I'm in and before it is subsequently validated. The change is dependant upon what the user types. When you're in the beforeupdate event, the celltext property doesn't work. Well, it does but then immediately reverts back to what the user had typed.
We've provided some keyboard shortcuts for monotonous data entry type tables; an example being that if the user types a single period and then moves on, then the cell will be updated to the same contents as the cell immediately above.
What happens now is the user will type a period, the contents of the cell above will be copied, displayed in the cell it is supposed to go in; validated as correct, then disappears and the period displays again.
I tried the celltext, recorddata and edittext properties but they all do the same thing. How can I force the cell to update to the text I want rather than the text the user typed if I'm in the beforeupdate event?
I guess it would work if the cell always went into edit mode but we don't always do that for some reason that I can't quite remember off the top of my head.
Just thinking out loud here without attempting to try this in the lab (because this is way too dangerous to do this at home! :-)), but what if you allowed a single period to pass through your validation logic (BeforeUpdate) and then in your AfterUpdate event handler you call the code that duplicates the cell contents from above?
I know that attempting to modify the content of the cell using code during the BeforeUpdate event handler is perilous.
Setting the Cancel property should put the cell into edit mode, thus avoiding the scenario you are describing. Your behavior is not expected and I suspect something else is not set up correctly.
I also forgot about the OnInvalidData event. You work with it the same way (i.e., by using the Cancel property), but it may feel more natural than using the BeforeUpdate event. However, this works only if you use the CellConv property. This might not fit within your design.
Looks like I've jumped down another rabbit hole but I think I'll revisit this with fresh eyes next week.
Your approach toward updating your validation logic is what I was thinking. Am I to infer that your core validation routines are not modeled after a traditional user-defined conversion (UDC) procedure? Thus, these are highly GUI sensitive?
I know there are always exceptions to the rules, but my rule is to avoid designing validation routines that cannot safely and predictably run in code (i.e., Oconv/Iconv) or at the dictionary level. This works with OI rather than against it. I then manipulate the GUI based on the success or failure of the UDC - which can remain in a nice one-liner function call.
The GUI one's are often wrappers around the traditional ones that just mean all conversions are the same be they in code, dicts or GUI but the GUI can also manage error handling etc.
I didn't design it but after using it for a while, I have found it quite convenient and find myself wanting for it when I'm coding in other systems. It's what you get used to I guess.
This sounds like a good design. As long as the true validation/conversion follows standard protocols then it makes a lot of sense to have useful wrappers that manage the high-level stuff in an automated fashion. We like things as easy as possible! :-)