Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (2)

Resolved Saving, Posting an event from itemchanged Event

  1. How-to
0
Votes
Undo
  1. David Vasconcelos
    David Vasconcelos
  2. PowerBuilder
  3. Thursday, 25 June 2020 15:46 PM UTC

Looking for some ideas for an issue regarding saving and events that are posted in the itemchanged event.

Simple Scenario...

Datawindow has a date field, the date entered must only be a business date. User enters a date, post event fires (this is because the date entered must be accepted by the datawindow in order for it to be adjusted later by the posted code since you cannot change the data within the itemchanged event), posted code checks the date to see if its a business date, if it is not it will adjust the date for the user to the next available business date. I.E. user enters June 13, which is a Saturday, not a business day so code will automatically adjust it to be Jun 15 which is the Monday and is a business day. All this occurs in a post event and then Sets the field with the new date.

Issue.

User has not moved off the field so the itemchanged has not fired off yet.

User then hits save which runs , accept text (itemchanged and post happens), validation functions then checks for all good return codes then does the save and checks for save return codes.  So when the accepttext fires off and the itemchanged event posts the routine to check the date, validation functions will fire off but won't have the new date since that code has been posted. Save fires off but saves the entered data since the posted code has not fired off yet.

Can't post the save since you need to look for return codes for success or not to be able to run any code after the save. i.e. Post save...

Interested in reading what others have done.

Thanks

Dave V.

SetRedraw() to reduce flickering
Pb12 preemptive authentication SOAP example
Accepted Answer
David Vasconcelos
David Vasconcelos Accepted Answer Pending Moderation
  1. Thursday, 25 June 2020 17:51 PM UTC
  2. PowerBuilder
  3. # Permalink

So for anyone reading this I may have thought of a solution that may work.  I can create an "alternate' column for the user to enter in the info but behind the scenes I can update the real column (not visible to the user) that will get updated to the DB.  I would not need to do a post since I would have access to the real column in the itemchanged event.

Hope this works..

Dave V.

Comment
There are no comments made yet.
Responses (2)
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 25 June 2020 19:05 PM UTC
  2. PowerBuilder
  3. # 1

Hi David;

   FWIW: What I have in my framework is a DW Control and DataStore ancestor with three instance variables for handling these types of issues:

  • Boolean  ib_ok_to_save
  • Boolean  ib_save_required
  • String     is_current_column

   When any data changes, the ib_save_required variable is set to TRUE. The of_Update() method cannot be fired unless the ib_ok_to_save variable is TRUE. In the of_update() method's processing, if the ib_ok_to_save variable is FALSE, then the DC/DS knows that POST processing event is probably still underway. So the update ignores and the request (but logging when in Debug mode).

   Each time an ItemChanged event is fired and before I POST a UE, I set the ib_ok_to_save to FALSE. Then in the Posted event (which receives the is_current_column as an argument), if everything is OK, I set the ib_ok_to_save to TRUE (logging this condition in Debug mode) and is_current_column is set to "". Depending on the error, the Posted UE informs the user of the error and/or change. This could just even be an informative message in the MDI's Micro Help bar.  So in theory, the control that initiates the SAVE, is only enabled when ib_ok_to_save and ib_save_required are all TRUE. Thus, the next iteration of the of_update() method should then perform the DC/DS updates to the DB for real.

  In more complex transactions, I use an of_validate_update() method that trips through an array of registered DC/DS's. It first checks all the registered DC/DS's ib_ok_to_save and ib_save_required variables are TRUE. If not, the method informs the user of the situation and returns focus & control to the 1st DC in error, for correction. If the suite of DC/DS's all return OK, then the SAVE feature is enabled and the actual of_update() can then processed.

  If the update processing is underway (validation says OK to proceed), then the of_update() method trips through the array of DC/DS's as they are registered in their firing order (that is their relationship in the DB as to whether they relate to a Parent or Child table). No DWO Row/Column flags are reset during this part of the processing cycle. Thus only at the end of the of_update loop, either the logical transaction completes OK and a Commit and ResetFlags is performed on the entire array of DC/DS or if it fails, the DC/DS's states are preserved and error control returns to the user for resolution.

Food for thought.  HTH

Regards ... Chris

Comment
David Vasconcelos
  1. David Vasconcelos
  2. Thursday, 25 June 2020 19:38 PM UTC
Thanks for the info Chris, my only question is in my case the save does need to proceed, but it needs to happen after all the post events. There are no errors just data being changed, so nothing would/should stop the save process. So when you mean that the save would be ignored if a post event was occurring how does it eventually save without any user intervention?
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Thursday, 25 June 2020 20:19 PM UTC
It doesn't until all the changes are processed by the Posted events and all errors are addressed by the App user.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.