PCL::Edit::OnEditCompleted() is dont drop modifiacion flag.

[NKV]

Hi.
There are strange behavior with event handler OnEditCompleted.
To understand the problem, modify SandBox code (just add output to console if modification flag is active):

Code: [Select]

void SandboxInterface::__EditCompleted( Edit& sender )
{
if ( sender == GUI->ParameterFive_Edit )
{
if ( sender.IsModified() )
Console().WriteLn("ParameterFive IsModified() == true");
instance.parameterFive = sender.Text();
}
}
Run SandBox and make Console always visible. Enter some value in ParameterFive_Edit. Click outside SandBox. You will see first message(IsModified) in console). Everything looking good.
Now, Click on Title Sandbox interface... Do you see additional 3 messages IsModified?

Is it normal?

Best regards,
Nikolay.

[Juan Conejero]

Hi Nikolay,

Once an EditCompleted event has been generated, the state of Edit::IsModified() isn't reliable. Don't rely on this member function in your EditCompleted event handlers. Instead, always work under the assumption that the text in the sender Edit control has been changed when you receive this event.

[NKV]

Juan, What about that situation:
I want check in OnEditCompleted() is entered value is correct. For example:

Code: [Select]

void SandboxInterface::__EditCompleted( Edit& sender )
{
if ( sender == GUI->ParameterFive_Edit )
{
if ( !File::Exists( sender.Text().Trimmed() ) )
{
MessageBox m("No such file!");
m.Execute();
sender.Clear();
}
instance.parameterFive = sender.Text();
}
}

How to avoid double MessageBox generation?

Can I do it via:

Code: [Select]

if ( !sender.IsModified() ) return;
sender.SetModified( false );?

[Juan Conejero]

Why the second message box? Are you getting it due to the call to Edit::Clear() ? In such case, then you've discovered a bug. Events are never (should never be) generated when the state of a control is modified programmatically. Events should be generated exclusively as a result of direct user interaction. Note that this is a design principle of PixInsight/PCL/PJSR.

So if you're getting a new (implicitly recursive) call to your SandboxInterface::__EditCompleted event handler as a result of calling sender.Clear(), then we have a high-priority bug.

A simple workaround is as follows:

Code: [Select]

void SandboxInterface::EditCompleted( Edit& sender )
{
   static bool busy = false;
   if ( busy )
      return;

   busy = true;

   try
   {
      if ( sender == GUI->ParameterFive_Edit )
      {
         String filePath = sender.Text().Trimmed();
         if ( !filePath.IsEmpty() )
            if ( !File::Exists( filePath ) )
            {
               MessageBox( "No such file!" ).Execute();
               sender.Clear();
            }
         instance.parameterFive = filePath;
      }

      busy = false;
   }
   catch ( ... )
   {
      busy = false;
      throw;
   }
}
I'll let you know if I find a bug in Edit::Clear() or similar member functions.

[NKV]

It's not Edit::Clear() problem, because without Edit::Clear() I have got same result.
Just try code:

Code: [Select]

void SandboxInterface::__EditCompleted( Edit& sender )
{
if ( sender == GUI->ParameterFive_Edit )
{
if ( !File::Exists( sender.Text().Trimmed() ) )
{
MessageBox m("No such file!");
m.Execute();
}
instance.parameterFive = sender.Text();
}
}
PS: Thanks for workaround code.

[NKV]

A simple workaround is as follows:

The workaround code is don't work properly...
Try manipulation1: Enter some value into ParameterFive_Edit and click by mouse outside SandBox GUI. You will see one MessageBox("No such file!"). Everything work fine, but now click MessageBox "OK" button and move mouse. Do you see that mouses modifier in wrong mode? Do you see blue selection rectangle. If you will try again and again, you can paint very nice picture. See attachment.

Also, you can see one more cursor bug: After manipulation1, enter some value, press "enter" (to confirm new value) and press "enter" to close MessageBox: Do you see Processing Cursor ( blue-green running circle )?