Synchronous vs Asynchronous

MARTINDRENOVAC

Don,

In another thread you stated "I would like to emphasize the following best practice concepts: Unless required, always qualify OLE events as asynchronous."

However, in the Frameworks Promoted Create event there is this code:
If Type EQ "OLECONTROL" then // Redirect the OLE event to the application level promoted event Qualify = "" Qualify<1> = 1 Qualify<3> = "" If Get_Property(@Window, "@DIALOG_BOX") EQ 1 then Qualify<4> = 0 ; // Asynchronous event processing end else Qualify<4> = 2 ; // Synchronous event processing end If EventExists then Qualify<2> = 13:"*":EventKey end Send_Message(Ctrl, "QUALIFY_EVENT", "ALL_OLES", Qualify) Are you saying in Frameworks we should reverse this logic and just make exceptions for OLE events that need to be qualified as synchronous, such as the EditTable BeforeUpdate event?

Thanks,

Don

DonBakke

Hi Don,

Yes, you are correct. This is a relatively recent policy shift on our part, largely due to changes in OI 9 that seem to cause performance and overhead issues with excessive synchronous event handling.

MARTINDRENOVAC

I had assumed as much from your comments on the other thread, but I just wanted to make sure before I started making changes.

Thanks Don for clarifying that.

Don

MARTINDRENOVAC

I have a few more questions:

1. Somewhere along the line, I got the impression that the SRP Picture control should be qualified Synchronously. Is this still true?
   
   
2. If the EditTable control is set Asynchronously, except for the "Before" events, might the BeforeUpdate-AfterUpdate etc. event chain order change? Or should the related "After" events also be Synchronous?
   
   
3. Except for possibly the SRP Picture control, the only SRP controls that need Asynchronous exceptions would be the "Before" events for the EditTable and Schedule controls, right?

Thanks.

Don

DonBakke

Don,

1. I think the SRP Picture control only needs the OnCustomDraw qualified synchronously. It is unlikely you need this event so I would ignore it.
   
   
2. The SRP EditTable Before/After event chain order will not change. Internally, the Before event handlers make a direct call to the After event handlers. So there is no way for these to get out of order. I suspect (but Kevin would need to confirm), that you only need to qualify the Before events as synchronous.
   
   
3. That is correct.
   

Something else I should have included in the aforementioned "best practices" post: we no longer advocate the qualifying of ALL_OLES. This again is related to performance. So the best practice approach is to only qualify thoses event you need. For third-party OLE controls that have little or no documentation, you may want to continue to use ALL_OLES in order to collect helpful information and then pair it down as you become familiar with it.

MARTINDRENOVAC

Hi Don,

After qualifying the EditTable generally as Asynchronous, I have discovered that qualifying only the EditTable "before" events as synchronous is not sufficient to guarantee the EditTable will behave as expected. You must also qualify the "after" events as synchronous, too.

I have certain Date and Time columns that do not get their data saved when moving off a cell directly to another row. These columns also involve the OnChar event (but I don't think the OnChar event is causing the problem). After the end of the BeforeUpdate event, but before the AfterUpdate, the values are being set to zero or null. The wrong values are Oconv'd and briefly flash in the cell, but are then immediately replaced with the correct date or time.

Basically, the correct values appear to remain in the EditTable, but the wrong values get saved. All I can say is that also qualifying the "after" events as synchronous, restored the EditTable behavior to its previous good working order. If you want to play it safe, my recommendation is to qualify the "after" events as synchronous, too.

I just thought I would make you aware of this.

Don

KevinFournier

Here is the exact event chain that occurs when the selected cell changes or the table loses focus:

• OnInvalidData (Fired if validation failed. If you don't use CellConv, then this never fires.)
  
• BeforeUpdate (Should be qualified as synchronous)
  
• AfterUpdate
  
• PosChanging (Should be qualified as synchronous)
  
• HScroll/VScroll (Only fires if changing cells caused a scroll)
  
• PosChanged
  

The first three events only fire if there was a change in the cell's contents. If BeforeUpdate is synchronous, then it is impossible for AfterUpdate to ever occur before that. That is because the ActiveX Control's code is on hold until OI finishes processing the event. The fact that making AfterUpdate synchronous helps you tells me you probable have logic in the PosChanging or PosChanged events that alter the contents of a cell. It is possible that when AfterUpdate is asynchronous that it occassionally gets processed after PosChanged. Normally, this is not a problem unless the PosChange events have cell altering logic.

At SRP, we follow these general rules of thumb:

• BeforeUpdate: validation logic only. No cell alteration.
  
• AfterUpdate: conversion logic and update of dependent cells (i.e., symbolics) only. Cell alteration okay.
  
• PosChanging: navigation validation logic only. No cell alteration. This is used to redirect where the user will go next if you do not want the default behavior.
  
• PosChanged: navigation response only. No cell alteration. If you had, for example, a status bar that showed some help text to the user for the current column, then you'd update that status bar here.
  

Is this the paradigm you follow? If so, then this is an intriguing mystery.

MARTINDRENOVAC

I do follow the rules of thumb you outlined above. There are times when I update hidden cells that are dependent on visible cells during the PosChanged event, but this does not effect the cells in question. Something seems to sneak in between the BeforeUpdate and AfterUpdate events.

All the columns in question have OnChar events that set the Modified property. These are Date, Time and Qty cells that use code in the OnChar event that allow the user to spin the values using the + or - keys. Because the spinning alters the cells programmatically, the Modified property is needed so the EditTable knows the cells have changed. But this triggers the BeforeUpdate/AfterUpdate event chain. Entering characters manually also sets in the Modified property. Whether entered manually or by "spinning", the data is lost if you move off the row, but not if you tab to the next cell.

Well, I'm guessing this might be part of the problem if the after events are asynchronous. I know that my particular situation in some way has to be related to what I have coded, but in general I still think its probably safer to qualify these after events synchronously. That is, unless you tell me this could cause different problems.

Thanks.

Don

MARTINDRENOVAC

I should have mentioned above that the OnChar event also sets the EditText and CellText properties.