Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Control Lostfocus
Hi
This is an unclear area to me, and I am raising within the button control section as this is where the issue has arisen for me.
I have an edit line control on a form with a Lostfocus event, which strips invalid characters from the field.
The field is a code, so I strip spaces and other things I want to enforce, such as quotes etc.
This works fine when the control loses focus to another OI control.
The problem arises when the control loses focus to an OLE button control.
The button in question is one that performs the action, in this case a project copy, which results in the copy being invalid as the characters are not stripped out.
In this case the lostfocus event does not fire, as it is not going to another OI control, but to a SRP control.
Even if I do a left click, hold and do not release and drag away, focus is not given to the OLE control, so the preceeding control does not lose focus.
I am not sure whether this is a bug in OI, in that it should still fire lostfocus, or whether as an OLE control, the ownership of issues relating to that is no longer part of OI control, and that the OLE control needs to trigger the check.
I have coded to avoid the issue, but it is something you may want to review.
Colin
This is an unclear area to me, and I am raising within the button control section as this is where the issue has arisen for me.
I have an edit line control on a form with a Lostfocus event, which strips invalid characters from the field.
The field is a code, so I strip spaces and other things I want to enforce, such as quotes etc.
This works fine when the control loses focus to another OI control.
The problem arises when the control loses focus to an OLE button control.
The button in question is one that performs the action, in this case a project copy, which results in the copy being invalid as the characters are not stripped out.
In this case the lostfocus event does not fire, as it is not going to another OI control, but to a SRP control.
Even if I do a left click, hold and do not release and drag away, focus is not given to the OLE control, so the preceeding control does not lose focus.
I am not sure whether this is a bug in OI, in that it should still fire lostfocus, or whether as an OLE control, the ownership of issues relating to that is no longer part of OI control, and that the OLE control needs to trigger the check.
I have coded to avoid the issue, but it is something you may want to review.
Colin
Comments
Certain styles of the SRP Button control do not generate LOSTFOCUS events by design. This was to make toolbar style buttons work as expected. What style are you using? If you change it to a non-toolbar style does it work?
The issue is NOT with the SRP button control losing focus, I accept that this event is under control of the OLE and therefore me.
The issue is the LostFocus event not being triggered by an OpenInsight control when going TO an SRP OLE button control.
Colin
I understood what you meant. Actually, this is why I spelled it as LOSTFOCUS since that is the OI event whereas the OLE event would normally be Lostfocus.
Anyway, as I said, this is by design. Think about it: you do not want your toolbar to invoke a LOSTFOCUS on the current control. This is not normal behavior with other applications but OI has always made this a challenge because OI push buttons always get focus.
I can understand that mouse moves etc would not gain focus, but Click might.
But, having said that I accept it is far better not to have the buttons gain focus.
For instance if your toolbar has Bold/Underline/Italics etc, then losing focus would play havoc with selected text and cursor positions.
All the more reason for better understanding of this area, which this wiki provides for future readers of this post.
Colin
Good examples. Another common one would be a button next to an edit line control that invokes the OPTIONS event. If the edit line has validation and the current entry does not pass validation, it will block the ability to execute the CLICK event of a regular push button. If the button is designed to fix the entry then being unable to leave the edit line would defeat the purpose of the push button.