If you wanted to send a message from one form to another, you could simply use sendmessage. This was deprecated in favour of using activate, a command which has become pretty much a catch-all for all sorts of earlier commands, including run, perform, and spawn. These all still work in Uniface 9.6, but as they were deprecated in Uniface 9.1, it's well worth trying to write these out of your code.
One example of this might be if you have retrieved multiple records in one form, and also have a second form open with related records in it; when you scroll through the occurrences in the first form you might want to post the primary key details through to the second form, so that only the records related to the current occurrence in the first form are displayed.
In order to do this, the first form would need to have code in the "Occurrence Gets Focus" <OGF> trigger, something like this...
As you can see, because sendmessage is now deprecated, it is not highlighted as a reserved word. You also get a compile warning like this...
warning: 1000 - Deprecated statement 'sendmessage' used
You then need to have some code to receive this message in your second form, which needs to be in the "Asynchronous Interrupt" <ASYS> trigger, something like this...
When using sendmessage or postmessage, $result will always be set to "message". The second value that you define will become the $msgid and then third value will become the $msgdata.
Please note: If the <ASYS> trigger in the called component is blank then the application <ASYS> trigger will be called, as defined in the start-up shell.
So what's the difference between sendmessage and postmessage? Can you simply go through and replace every sendmessage with a postmessage, or should you be using activate instead?
Well the difference is that sendmessage is synchronous and postmessage is asynchronous, which means that potentially there's a delay before the message will be received and processed with a postmessage. Using an activate would be synchronous but you'd need to rewrite your code, probably moving the code in the <ASYS> trigger into an operation and then calling that from the <OGF> trigger.
Is this potential delay likely to cause a problem though? Well for starters, can we see it in practice? The answer to this is "yes", by putting sending code like this somewhere in a form (I went with the <EXEC> trigger)...
And then putting the receiving code in the <ASYS> trigger, like this...
We can then run the form and view the message buffer...
Before sendmessage
In ASYS: ID=MESSAGE, DATA=SENDMESSAGE
After sendmessage
Before postmessage
After postmessage
In ASYS: ID=MESSAGE, DATA=POSTMESSAGE
As you can see, the sendmessage happens between the "before" and "after" (synchronously), whereas the postmessage happens at the very end (asynchronously). This means that you have to be very careful about changing any sendmessage statements into postmessage statements - the code order will change, and you need to be aware of this and check this will not cause a problem.
As far as my testing has gone, the messages are always received and processed in the order that they were posted, as you may expect from a message queue. Having said that, I've not found anything in the manuals that states explicitly that this order is enforced, so writing code that relies on the messages being processed in a particular order might not be wise.
Summary: The deprecated sendmessage command was sychronous whereas the postmessage command is asychronous, so you must be careful if you replace one with the other. However, this is likely to be more straight forward than replacing with the activate command, as the manual suggests.
One example of this might be if you have retrieved multiple records in one form, and also have a second form open with related records in it; when you scroll through the occurrences in the first form you might want to post the primary key details through to the second form, so that only the records related to the current occurrence in the first form are displayed.
In order to do this, the first form would need to have code in the "Occurrence Gets Focus" <OGF> trigger, something like this...
sendmessage "SECOND_FORM","PKEY","FIELD1.ENT=%%FIELD1.ENT%%%"
As you can see, because sendmessage is now deprecated, it is not highlighted as a reserved word. You also get a compile warning like this...
warning: 1000 - Deprecated statement 'sendmessage' used
You then need to have some code to receive this message in your second form, which needs to be in the "Asynchronous Interrupt" <ASYS> trigger, something like this...
the_result = $result ;will be
"message"
message_id = $msgid ;will be
"PKEY"
message_data = $msgdata ;will
be "FIELD1.ENT=xxx"
When using sendmessage or postmessage, $result will always be set to "message". The second value that you define will become the $msgid and then third value will become the $msgdata.
Please note: If the <ASYS> trigger in the called component is blank then the application <ASYS> trigger will be called, as defined in the start-up shell.
So what's the difference between sendmessage and postmessage? Can you simply go through and replace every sendmessage with a postmessage, or should you be using activate instead?
Well the difference is that sendmessage is synchronous and postmessage is asynchronous, which means that potentially there's a delay before the message will be received and processed with a postmessage. Using an activate would be synchronous but you'd need to rewrite your code, probably moving the code in the <ASYS> trigger into an operation and then calling that from the <OGF> trigger.
Is this potential delay likely to cause a problem though? Well for starters, can we see it in practice? The answer to this is "yes", by putting sending code like this somewhere in a form (I went with the <EXEC> trigger)...
putmess "Before sendmessage"
sendmessage "TEST_PERF","MESSAGE","SENDMESSAGE"
putmess "After sendmessage"
putmess "Before postmessage"
postmessage "TEST_PERF","MESSAGE","POSTMESSAGE"
putmess
"After postmessage"
And then putting the receiving code in the <ASYS> trigger, like this...
putmess "In ASYS:
ID=%%$msgid%%%, DATA=%%$msgdata%%%"
We can then run the form and view the message buffer...
Before sendmessage
In ASYS: ID=MESSAGE, DATA=SENDMESSAGE
After sendmessage
Before postmessage
After postmessage
In ASYS: ID=MESSAGE, DATA=POSTMESSAGE
As you can see, the sendmessage happens between the "before" and "after" (synchronously), whereas the postmessage happens at the very end (asynchronously). This means that you have to be very careful about changing any sendmessage statements into postmessage statements - the code order will change, and you need to be aware of this and check this will not cause a problem.
As far as my testing has gone, the messages are always received and processed in the order that they were posted, as you may expect from a message queue. Having said that, I've not found anything in the manuals that states explicitly that this order is enforced, so writing code that relies on the messages being processed in a particular order might not be wise.
Summary: The deprecated sendmessage command was sychronous whereas the postmessage command is asychronous, so you must be careful if you replace one with the other. However, this is likely to be more straight forward than replacing with the activate command, as the manual suggests.
