1. Miguel Leeuwe
  2. PowerBuilder
  3. Friday, 4 December 2020 17:10 PM UTC

I have a richtext edit control and I'm trying to figure out if a user has done any changes or not, before closing the window.

I've tried the modified event without success. I rarely seems to fire.

I've tried the key-event (pbm_rnkey) without success: it only seems to be triggered for keys like ctrl, shift, alt, backspace, etc.

I've tried the pbm_keyup and -down, no success.

If I just typ an 's' those events aren't fired. Is this a bug maybe?

I know that edit controls have a more limited information in the key events. Like you cannot ask for the keyflags in combination with the key parameter.

I need to set a boolean like ib_changed = true, to be able to know whether I have to ask to save changes or not, when a user does ALT+F4. (mind that ALT would trigger the key event).

When / Where could I set this?

The only way out that I see at this moment, is to save the original contents when opening the window and comparing it against whatever contents there is at the moment of saving.

I was hoping for a more elegant way of doing this.

Any ideas are welcome,

TIA

Accepted Answer
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Saturday, 5 December 2020 08:58 AM UTC
  2. PowerBuilder
  3. # Permalink

All the things you learn when making a small sample application :)

It's not a bug! 
[EDITED 12th Dec '20]: If I only would have read a bit further in the help on the modified event, to what's said below "Usage", it's very clearly explained what I learned the "hard way" It literally explains things: 

For InkEdit and RichText Edit controls, the value of the Modified property controls the Modified event. If the property is false, the event occurs when the first change occurs to the contents of the control. The change also causes the property to be set to true, which suppresses the Modified event. You can restart checking for changes by setting the property back to false.

Resetting the Modified property is useful when you insert text or a document in the control, which triggers the event and sets the property (it is reporting the change to the control's contents). To find out when the user begins making changes to the content, set the Modified property back to false in the script that opens the document. When the user begins editing, the property will be reset to true and the event will occur again.

Thank you all, Mark Goldsmith for pointing out the modified property, Chris for suggesting to use a dw and Armeen for suggesting to make a sample app, which led me to play around with this thing.

(probably not very useful but since I made it already, I've attached my PB2019 sample app).

 

regards

Attachments (1)
Comment
  1. Mark Goldsmith
  2. Saturday, 5 December 2020 13:39 PM UTC
Great to hear you got it resolved Miguel and thanks for the detailed update!
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Saturday, 5 December 2020 16:48 PM UTC
Thanks for the detailed explanation!
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Monday, 7 December 2020 10:24 AM UTC
  2. PowerBuilder
  3. # 1

Today I started to apply what I've learned with this post, in all of our applications:

I've managed to make the modified() event behave in a similar way as the editChanged() event of a dw:

- in my pfc ancestor class "u_rte", I've added 2 instance variables. One to indicate that I want the modified to behave like an editChanged event and one to indicate that there's been at least one change "ib_changed". (since I'm going to reset the "modified" property of the control constantly, I need that ib_changed variable to check if there were changes when closing the window.

- in the modified of u_rte, I set ib_changed to TRUE and call a user event "ue_reset_modified()" with POST. This will cause the modified to be triggered for every change done to the contents.

 

I thought maybe anyone might find this useful.

I've exported and attached my u_rte object  [EDIT]: I've removed the attachment, it needs some modification of the key event, I'll re-attach it later.

I haven't tested anything yet !

regards.

Comment
There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Friday, 4 December 2020 18:12 PM UTC
  2. PowerBuilder
  3. # 2

Hi Miguel, Which RichText engine are you using and what is your PB version including build #?

Comment
  1. Miguel Leeuwe
  2. Thursday, 10 December 2020 01:25 AM UTC
Hi Chris, that's what I initially did. Use an instance boolen which I would set in the pbm_renkey. Didn't work for me though, since I have shortcut keys in a menu for cut, copy, paste, undo.

When hitting Alt+F4 or Ctrl+F4 to close windows, the execution of the key event for the ALT key would set the boolean and it would always seem I would have changes. :)

Setting the rte_1.modified property to false in a POST triggered event or function did solve my situation. I managed to get the modfied event to behave similar to EditChanged(). So I do set an ib_modified variable to know if I had changes, but it's done from the modfied event. No more need for key event.

regards.

  1. Helpful
  1. Miguel Leeuwe
  2. Thursday, 10 December 2020 01:28 AM UTC
Having shortcuts on the menu did not allow me to check on a key combination of ALT+F4 either. Keyflags and key parameters would always be the same.

For exampley keyflags would be 2 (control key) and key would also be keyCtrl!.

At first I thought it was a bug, but if you don't use a menu with shortcuts, everything works as expected.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Thursday, 10 December 2020 19:07 PM UTC
Hi Miguel;

There are no issues in my approach as I am using a "framework" of polymorphic objects. In the case of Menus, any "Short-cut" is trapped by the Menu object 1st because it's reading the O/S Message Queue first and does not "chain" the message ID back on to the O/S queue when it's done with it (by design). Hence the message just gets lost in the proverbial "bit bucket" garbage can. So the expecting control never knows about it when finally gets a chance to read from the O/S message queue.

The DataWindow Control also does this early message queue processing but more often that not, "chains" the message ID back on to the O/S queue so that your App(s) can see it.

In the case of my framework that uses: message redirection, polymorphism and inheritance, the problem is solved because the Menu does intercept the O/S message from the queue but, then reroutes this to the control in question after processing it. It does this by using the GetFocus() command with the use of "Inclusional" & "Operational" polymorphism to reroute a new message to the current control. For example... A Menu traps the CTRL+V for the RTE Control. However, the menu locates the current control and if editable, sends an "oe_paste" user message to the control after it handles whatever the CTRL+V means to the menu. Thus both objects possess a "symbiotic" relationship at all times.

I think in your case, the KEY event implementation might have been hampered because you were not within the bounds of a framework that takes care of these type of processing relationships. Just a guess on my part.

HTH

Regards ... Chris
  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.