1. Ashutosh Varshney
  2. PowerBuilder
  3. Wednesday, 25 July 2018 18:39 PM UTC

Hello,

I have run into a strange issue with the Itemchanged event. I am running PB2017R2. I have some code in the itemchanged event of a datawindow.

MessageBox ('', 'ok')
Return (2)

This should reject the changes made - No matter what. Instead this always allows the change to go thru. If I comment the MessageBox then the datawindow rejects the value as expected.

Anyone else experienced this? Any solutions or workarounds?

Thanks.

 

Accepted Answer
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 25 July 2018 21:43 PM UTC
  2. PowerBuilder
  3. # Permalink

Okay, Chris you're absolutely right.

I tried Chris' code and indeed it works without doing a POST for the Messagebox. This left me a bit off my feet, I've been coding the itemchanged since 1992 ... :s

So then I tried with numeric fields with format thinking that maybe a format or editmask might make a difference.

No luck, it still works perfectly.

Then I wondered why during all the years I've been seeing similar problems and I think I know what's going on here:

A lot of people (including companies I worked for), use some kind of an ancestor for the dw control and lots of times they / we code an "AcceptText()" command in the losefocus event of the datawindow to make sure all values are being validated, etc.

So I've added that (an AcceptText() ) to the losefocus event and now I can reproduce the problem that Ashutosh is experiencing:

The Messagebox makes the losefocus do an AccepText() and that's makes the "return 2" lose track of it's buffer values.

So if there's an AccepText() anywhere in the itemchanged itself or most probably in the losefocus event ....
take that out and it will work the way Chris describes.
I you cannot or don't want to take out the AcceptText, then choose my workaround of doing an Post of the Messagebox or the other described method of first saving the original value.
 
I've added a very small app that reproduces the problem with the AcceptText() in the losefocus()
 
HIH.
 

 

Attachments (2)
Comment
  1. Miguel Leeuwe
  2. Wednesday, 25 July 2018 21:45 PM UTC
Wow, that doesn't look very well .. let me try to align that text again, this time without the indent:



The Messagebox makes the losefocus do an AccepText() and that's makes the "return 2" lose track of it's buffer values.

So if there's an AccepText() anywhere in the itemchanged itself or most probably in the losefocus event ....

take that out and it will work the way Chris describes.

I you cannot or don't want to take out the AcceptText, then choose my workaround of doing an Post of the Messagebox or the other described method of first saving the original value.



I've added a very small app that reproduces the problem with the AcceptText() in the
  1. Helpful
There are no comments made yet.
Ashutosh Varshney Accepted Answer Pending Moderation
  1. Thursday, 26 July 2018 14:22 PM UTC
  2. PowerBuilder
  3. # 1

Thanks Chris. And Thanks to Miguel as well.

Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 26 July 2018 00:23 AM UTC
  2. PowerBuilder
  3. # 2

Hi Miguel;

    Yes ... never, ever, ever and if in doubt ever perform an AcceptText() within a DC/DS event!   tongue-out

Regards ... Chris

Comment
  1. Ashutosh Varshney
  2. Thursday, 26 July 2018 11:02 AM UTC
Miguel, Chris,

Thanks for your response.

Indeed in my case there is an AcceptText in the loosefocus event of the dw. I will try your workaround.

In all these years I assumed that since the Messagebox is a modal dialog, no other script or events would be processed untill it was dealt with including loosefocus.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Thursday, 26 July 2018 13:44 PM UTC
Hi Ashutosh;



Yes, the MB() is modal. However, the issue in many cases is that the DC/DS event that is forcing the ItemChanged event needs to complete first before processing of the IC event can be done properly.



I am glad though that I finally was able to straightened you guys out on this issue after all these years - LOL!

Have a super day!



Regards ... Chris

Have you hugged your DataWindow today? ;-)
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 25 July 2018 20:38 PM UTC
  2. PowerBuilder
  3. # 3

Hi Miguel;

   FYI  I just checked the following code in PB versions 11.2, 11.5.1, 12.1, 12.5.1, 12.6 and R2 and it worked properly on the ItemChanged with a MessageBox! If I answered NO, the original value reappears in the DWO's primary buffer and the column's state is reset to NotModified. If I say YES, the new value takes effect and the column's state is set to Modified.

Int            li_rc
String        ls_name
ls_name = String (dwo.name)
li_rc    =    MessageBox ( "Data Changed", "For '" + ls_name + "'" + "~rAccept?", Question!, YesNo!, 2)
IF  li_rc = 2 THEN
    return 2  // Reject
else
    Return 0 // Accept
END IF

 

So this processing that Ashutosh wanted to do should have worked!  If not, this is a bug - but, I cannot reproduce it.

Note: I also tested this issue using Ashutosh's use of the parenthesis on the Return command and it worked as well!

           (that was  legal syntax way-back-when).  

HTH

Regards ... Chris

Comment
  1. Miguel Leeuwe
  2. Wednesday, 25 July 2018 20:45 PM UTC
Yeah, way back then in the days of SetActionCode() :).

Okay, so I might have been using very old knowledge (from before the versions you have tested right now?).

I'll give it a go myself and see if I can reproduce Ashutosh's bug then. If so I will let you know.



Thanks for checking.
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 25 July 2018 19:40 PM UTC
  2. PowerBuilder
  3. # 4

(don't know why the answers and comments seem to get mixed up here chronologically, sorry probably my fault)

Comment
  1. Armeen Mazda @Appeon
  2. Wednesday, 25 July 2018 19:46 PM UTC
Not sure if I understand the problem you are experiencing. The default sort criteria is latest answer so the most recent answer (not comment) would be at the top unless the author has accepted a particular answer as the correct one, in which case that answer would be at the top. Comments under a particular answer are sorted oldest first. A new comment under an answer doesn't push the answer to the top.
  1. Helpful
  1. Miguel Leeuwe
  2. Wednesday, 25 July 2018 19:50 PM UTC
Yes Armeen, that's why I said it's probably my fault, I must have commented on Chris' comment instead of my own. I love the way this site improved by the way. We have had to wait a while, but It's GREAT!
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Wednesday, 25 July 2018 23:24 PM UTC
Glad to hear you like the new site better, and sorry it took so long!
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 25 July 2018 19:37 PM UTC
  2. PowerBuilder
  3. # 5

Hi Chris,

Sorry but as far as I know, this is the way itemchanged has always worked:

The messagebox() takes the focus of the dw and ...bla bla bla ... the buffer (see my previous comments here).

You have to do a POST Messagebox and then return 2.

Or ....

save the original value with getitem and store it in a variable, then do the messagebox (without the post) then do a setitem() and then do the return 2.

HIH

Comment
  1. Chris Pollach @Appeon
  2. Wednesday, 25 July 2018 19:44 PM UTC
That does not make sense as a POST will then allow the ItemChanged event to complete and allow the data to change in the primary buffer. Returning a 2 in the Posted event will have NO effect as its not tied to the ItemChanged event processing.
  1. Helpful
  1. Miguel Leeuwe
  2. Wednesday, 25 July 2018 19:48 PM UTC
Sorry Chris, I didn't say that we are doing a "posted return 2" only the messagebox
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 25 July 2018 19:27 PM UTC
  2. PowerBuilder
  3. # 6

     OK thanks ... that is the latest build of PB2017R2! So then it would seem that this could be a bug in the current DC/DS implementation. I would like to suggest that you open a support ticket on this issue.

 

     As far as a workaround ... if you do not need the MessageBox() command for your processing flow - then removing it should not be an issue to complete your implementation. However, if you do need to ask the business user if they want to accept the changes via a MB() command, then the current behaviour would not be acceptable. The only thing that I can think of off-hand - if the user wants to reject the data - is after the MB() command, proceed as follows:

  • Use the SetItemStatus() command to reset the column's data state to NotModified!
  • Then restore the column's data in the primary buffer from the value in the original buffer

Note: You may also need to restore the Row status flag as well.

HTH

 

Comment
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 25 July 2018 19:20 PM UTC
  2. PowerBuilder
  3. # 7

Your messagebox takes the focus off the datawindow. That will make the itemchanged event to have "accepted" the change already in it's buffer before returning the 2 value.

Do an POST Messagebox(..) and your return 2 will work fine.

 

Comment
There are no comments made yet.
Ashutosh Varshney Accepted Answer Pending Moderation
  1. Wednesday, 25 July 2018 19:04 PM UTC
  2. PowerBuilder
  3. # 8

I am using build 1769.

Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 25 July 2018 19:00 PM UTC
  2. PowerBuilder
  3. # 9

Hi Ashutosh;

   What build of PB2017 are you using?

Regards ... Chris

Comment
  1. Miguel Leeuwe
  2. Wednesday, 25 July 2018 19:23 PM UTC
If you cannot afford the messagebox to appear "after" the execution of the event. Then do the following:

1) Do a GetItem...() of the field BEFORE showing the messagebox() and assign it to a variable. (this will get the value before the change that provoked the Itemchanged to happen).

2) Then do the Messagbox()

3) Then do a SetItem of the variable with the saved value right before the return 2.

4) return 2.
  1. Helpful
  1. Miguel Leeuwe
  2. Wednesday, 25 July 2018 19:24 PM UTC
Another thing: don't do a "return (2)" but do a "return 2", without the parenthesis.
  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.