Fatals in Eventloop, build 257

[Tom]

Hi, Roger.

We have lots of customers using our apps with build 257, and not few of them are complaining about frequent fatal errors. Most of them are created in _DCGETBX.PRG at lines 4550 or 4060, which is this code:

Code: Select all

4550: oXbp:handleEvent( nEvent, mp1, mp2)

Code: Select all

4060: nEvent := AppEvent( @mp1, @mp2, @oXbp, IIF( Empty(nTimeOut), IIF(Empty(::keyboardQueue),nWait,1), Min(nWait,10) ) )

Most of the fatals are "Non recoverable errors". I intensively work with subclassing (browses, statics). We may get those errors for a long time, but we installed a system to trace them a few month ago, so we now get information about this. To be honest, we can't reproduce the problem. Two questions:

1. Do you know that problem? Is that fixed in 260?

2. I assume that there is an object involved almost having no "handleEvent" method, for what reason ever. Could that be the cause? I added this code around lines 4550 and 4060:

Code: Select all

IF IsMethod(oXbp,'handleEvent')
 * lines 4550 and 4060
ENDIF

Could that help? In my first tests, everything works fine, even in my selfbuilt controls, but I'm a little afraid to create new errors instead of removing old ones.

I'm sorry asking for support for an older version, but 260 will be in our next release.

[rdonnay]

Tom -

The line numbers you refer to do not match up with my build 257 source code.
It appears that you have added about 20 lines of code to _DCGETBX.PRG in build 257.

Code: Select all

I assume that there is an object involved almost having no "handleEvent" method, for what reason ever. Could that be the cause?

It is possible that an object may not have a handleEvent method, but the only way I see this happening is if you have a PostAppEvent() call and pass it incorrect parameters. Regardless, I don't believe that it should cause a fatal error. Instead, the normal error handler would be invoked and you would get a "object has no method with this name:" error.

I'm concerned that a memory corruption is more likely at fault here.

I intensively work with subclassing (browses, statics)

I don't see why subclassing should cause such problems. I do know, however, that you also use a lot of owner-drawing, and it may be related to a malfunction in that system. Owner-drawing is performed in another thread and care must be taken to not output anything to the screen in your owner-drawing function. For example, calling WTF in the ownerdraw thread will lock up the system.

Jack Duijf has contributed much over the past few years. This was added in build 260.
Also, he made some improvements to his tooltip system to prevent fatal errors.

Code: Select all

  IF Valtype(oXbp) == 'O' .AND. IsMethod(oXbp,'HandleEvent')
    IF !oGetList:IsDesignOn .OR. oParentDlg == NIL .OR. oXbp == oParentDlg
      IF nEvent == xbeP_Quit
        QUIT
      ENDIF
      //
      // J. Duijf 17-07-2014
      // Required for my cell-edit class Dc_xbpCellEditBrowse
      //
      If nEvent <> xbeP_Keyboard
         oXbp:handleEvent(@nEvent,@mp1,@mp2 )                                 // J. Duijf 17-07-2014  Pass event parameters by refference
      Else
         //
         // Jack Duijf 17-07-2014
         // Sometimes is is NOT possible to signal that the key has been
         // processed. This results in double handling, or (in case of <Enter>) unwanted behaviour
         // If the ::keyhandlingcompleted is set, then further processing is suppressed.
         //
         ::keyhandlingcompleted              := FALSE
         oXbp:handleEvent(@nEvent,@mp1,@mp2 )                                 // J. Duijf 17-07-2014  Pass event parameters by refference
         If ::keyhandlingcompleted
            mp1      := 0
            nEvent   := xbe_None
         Endif
      Endif
      //
    ENDIF
  ELSE
    BREAK
  ENDIF

[Tom]

Hi, Roger.

You're right, I added some code before the mentioned line.

I'm aware of the situation that ownerdrawing works in conjunction with the UI thread and should not try do use any other output area except the known/handed presentation space. Maybe the drawing process is still running while an error was created elsewhere, which causes the standard errorhandler to lock up. Sometimes, we receive "Error within the errorhandling" from the same lines of code.

I'm going to compare 257 and 260 or maybe recompile our actual release using 260.

Thanks! Have a great weekend.