1. René Ullrich
  2. PowerBuilder
  3. Thursday, 7 November 2019 11:55 AM UTC


I have a problem with posted events.

Here a small simplified example of code:

POST Event ue_posted_event()
MessageBox ("", "test")
Event ue_triggered_event()

In this case the code in ue_posted_event is called after the code in ue_triggered_event. This is expected behaviour.


Now a simple change:

POST Event ue_posted_event()
open (w_response)   // w_response is a response window
Event ue_triggered_event()

I expect the same behaviour. But here ue_posted_event is called before ue_triggered_event. It is called after the open event of w_response.



How can I get the same behaviour as with MessageBox?



Who is viewing this page
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Friday, 8 November 2019 09:00 AM UTC
  2. PowerBuilder
  3. # 1

this is my proposed n_cst_error.of_processmessage(), I've also attached it so tabs are being maintained. You have to rename it to .txt as that's not an allowed type. I've renamed the txt to zip, but it's just txt.

The only thing I still have to check is the ii_style variable. To test it, I changed it to 1 in debug mode, but after another call to the messagebox it's still 1. So I might still get back on this. Also there's no more user interaction, whichever was allowed on the response window, other than choosing a button. Maybe, if you need that functionality, instead of overriding ii_style = 1, you would have to add a new ii_style = 2 for your "problem cases".


// u5, mjl, 15/11/18: appeonWeb doesn't like dots in parms:
//li_ret = super::of_processmessage()

gbl_errmess = true

// Function: of_ProcessMessage
// Access: protected
// Arguments: None.
// Returns: integer
// The button returned from the message window.
// -1 if an error was encountered.
// Description: This function is called to process the Message.
// Revision History
// Version
// 5.0 Initial version
* Open Source PowerBuilder Foundation Class Libraries
* Copyright (c) 2004-2017, All rights reserved.
* Redistribution and use in source and binary forms, with or without
* modification, are permitted in accordance with the MIT License

* https://opensource.org/licenses/MIT
* ====================================================================
* This software consists of voluntary contributions made by many
* individuals and was originally based on software copyright (c)
* 1996-2004 Sybase, Inc. http://www.sybase.com. For more
* information on the Open Source PowerBuilder Foundation Class
* Libraries see https://github.com/OpenSourcePFCLibraries

Integer li_rc
Integer li_testrc

// Set other information.
inv_errorpass.idt_date = DateTime(today(), now())

// As appropriate, run the attended/unattended process.
If ib_unattended Then
// Set the Default button as the return button for unattended mode.
inv_errorpass.ii_buttonclicked = inv_errorpass.ii_default
li_rc = inv_errorpass.ii_default

// powerserver / appeon web doesn't like "." in arguments to function calls:
string ls_title, ls_text
icon licon
button lbtnStyle
int li_default

ls_title = inv_errorpass.is_title
ls_text = inv_errorpass.is_text
licon = inv_errorpass.ie_icon
lbtnStyle = inv_errorpass.ie_buttonstyle
li_default = inv_errorpass.ii_default

// Attended Mode. Open response window.
Choose Case ii_style
Case 0

// inv_errorpass.ii_buttonclicked = of_MessageBox('pfc_errorsrv_msg', &
// inv_errorpass.is_title, &
// inv_errorpass.is_text, inv_errorpass.ie_icon, &
// inv_errorpass.ie_buttonstyle, inv_errorpass.ii_default)

inv_errorpass.ii_buttonclicked = of_MessageBox('pfc_errorsrv_msg', &
ls_title, &
ls_text, licon, &
lbtnStyle, li_default)
Case 1
// Set the timeout option.
inv_errorpass.ii_timeout = ii_timeout

If ib_beep Then
End If

// v1, mjl, 08/11/19: use a real messagebox, not a response window, as a response window changes the way the messages on the stack are being executed:
//li_testrc = OpenWithParm(w_message, inv_errorpass)
n_msgbox ln_msgbox
li_testrc = ln_msgbox.of_messageboxtimeout( ls_title, ls_text, licon, lbtnStyle, li_default, ii_timeout)
inv_errorpass.ii_buttonclicked = li_testrc

// v1, mjl, 08/11/19: commented:
// If li_testrc > 0 Then
// // Get the structure passed by the response window for
// // any user input and buttonclicked.
// If IsValid(Message.powerobjectparm) Then
// inv_errorpass = Message.powerobjectparm
// End If
// End If
End Choose
End If

// If appropriate, log the error.
If (inv_errorpass.ii_severity >= ii_logseverity) Then
li_testrc = of_ProcessLog ()
End If

// If appropriate, send a notification.
If (inv_errorpass.ii_severity >= ii_notifyseverity) Then
li_testrc = of_ProcessNotify()
End If

gbl_errmess = false
return inv_errorpass.ii_buttonclicked

Attachments (1)
Hi Miguel,

Thank you for your suggestion.

The problem is, that we usually want to use w_message because we have some extensions to this window we will use and that normal MessageBoxes do not have.

Seems to me that I may not have all I want. :-(

But I think it's a general problem if execution order of script depends on such things.
  1. René Ullrich
  2. Friday, 8 November 2019 09:13 AM UTC
True, it would be nice if response windows would behave the same way as modal dialogs. So I guess your only options are to get rid of the POST events then, at least in some places.
  1. Miguel Leeuwe
  2. Friday, 8 November 2019 09:57 AM UTC
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Friday, 8 November 2019 08:06 AM UTC
  2. PowerBuilder
  3. # 2

Hi Rene, we use pfc's so this is what I think you might do to solve the problem:

The only place where I see with PFC that the w_message is being used, is in: pfc_ncst_error.of_processmessage()

Added to that, "ii_style" needs to be 1, if ii_style = 0 it would still result in a real Messagebox. The ii_style = 1 is for giving messageboxes with a timeout. At least that what I see so far.

You could do an overload of the of_processmessage() by defining that function in the n_cst_error object.

In the choose case statement on ii_style, CASE 1: do something else than showing the w_message.

Roland Smith has documented how to use a normal Messagebox with a Timemout:


That way you only use "real" messageboxes, unless you have used the w_message in other places in the application. You'd have to replace these also with Roland's msgbox when they need a timeout.


As a matter of fact, thanks to your question, I'll implement this myself in our pfe's. When I'm done, coffee, shower, drive to work, and a bit of coding, I'll post the n_cst_object here which we use. Give me 2 hours.
  1. Miguel Leeuwe
  2. Friday, 8 November 2019 08:09 AM UTC
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 7 November 2019 20:20 PM UTC
  2. PowerBuilder
  3. # 3

Hi René;

   Try changing your code to ...

POST Event ue_posted_event()
MessageBox ("", "test")
Event ue_triggered_event()


Regards ... Chris

Hi Chris,

this makes the Messagebox behaves like a response window.

But what I want is the opposite.

Thank you!
  1. René Ullrich
  2. Friday, 8 November 2019 06:15 AM UTC
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Thursday, 7 November 2019 12:58 PM UTC
  2. PowerBuilder
  3. # 4

Hi René,

  • MessageBox wraps a Windows O/S call to a process modal message
    • Call stack remains intact
    • Process queue remains intact
    • Timers continue to run - blocked window receives Timer events despite the "block".

  • Response window is a PowerBuilder window type that blocks ONLY current code sequence
    • Call stack remains intact
    • Process queue continues to be processed (posted calls processed after dialog opens)
    • Timers continue to run - blocked window receives Timer events despite the "block".

I don't know of any way to block process queue while response window dialogue remains open.

But I can "solve" the other half of the equation: How to process event queue while message box displays!

// -- -- -- -- Code opening the message box -- -- -- --
// Continue event queue processing after short delay

// Display process modal dialog
MessageBox("Hello", "World!")

// -- -- -- -- Timer event of "main" window -- -- -- --
// Stop timer

// Process event queue
do while Yield(); loop

HTH /Michael

Ha, I was about to answer the same thing. I tried to something like recursively posting the ue_post event from itself with a yield, while the response window is open. (just as an experiment). Strangely enough that managed to run the posted event after closing the response, but then the triggered event is not run until you close the main window. Very weird.

So yes, I totally agree, the answer here is "You cannot".
  1. Miguel Leeuwe
  2. Friday, 8 November 2019 02:03 AM UTC
Hi Michael, hi Miguel,

Thank you for your explanations.

My problem is: I use PFC and there is a response window for displaying messages instead of using MessageBox.

The call stack in my application is much more complicated as in my example.

In my real case the triggered event causes in one of the subroutines in the deep of the code an error because of an external call and shows the response window to display the message. This causes a posted event to start at an unexpected moment. So the complete call stack gets disordered what causes unexpected behavior.
  1. René Ullrich
  2. Friday, 8 November 2019 06:25 AM UTC
Yeah, that's a hard one to crack!

I have mostly worked in non-PFC apps since 2012 so I hope someone else reading this thread had your issue and found a workaround. Anyone?
  1. Michael Kramer
  2. Friday, 8 November 2019 06:46 AM UTC
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.