SV: $O-8.0.3 x64 - Mac OS 10.12.5 : crash on "enter data" : solved thanks to Kelly

[Kelly Burgess]

Daniel wrote:
>Is this a normal behaviour?
>It must be a bug.

I didn't see Jean-Marc's code, but I had problems back in Studio 4 in this scenario:

I'm in Enter data, and on OK I want to validate the user's entries before proceeding, so my window $event would call a method that returned the name of the invalid data column, if any, at which point I would alert the user.  But I would do this not with an OK message, I used a custom OK message window which had an Enter data in it to pause it, waiting for a click or carriage return to dismiss it.  All the while, I am still in the evOK handler of the outer Enter data, and I want to return to that after notifying the user about the problem.  I found that I had to prevent a problem by issuing the Process event and continue (discard event) before I opened my custom OK message window and invoked another Enter data.

When Jean-Marc said that a breakpoint prevented the crash, my idea was that some kind of redraw, or return to idling, was added by the breakpoint that didn't normally occur.  After suggesting that he should be sure his Enter data command was not in the window's $construct method (which can also bring on this sort of problem), and learning that his Enter data was in another method that ran *after* the $construct had completed and the window was fully instantiated, I suggested the Process event and continue, which can often help Omnis get back to idling, or somehow get finished with one state before entering another.  The discard event option is useful to clear the decks in many cases, whether it's an evClick or evOK, and it sounds now like JM did have a nested Enter data, so pretty much the same as what I'd dealt with back in Studio 4.

Kelly