VK_F5 behavior CXTPReportInplaceEdit::OnKeyDown

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   XTP V13.2.1
I am chaining back my calls to OnKeyDown when I am not processing them.  The tookit behavior process the F5 key from within my edit control of an item to call the report control's Recalc method:
_pControl->Recalc(TRUE);
which immediately calls EditItem(NULL), which currently deletes my edit control.

Hence, when I return back, my edit control is GONE - window handles are 0xdddddddd, etc. So MY code ends up crashing (asserting) because my object thinks it's still around (which it is not because of the call to EditItem(NULL)).

What is the expected behavior of F5 when editing an item in a report control?  I search the source code for VK_F5 within the entire XTP toolkit (not just Report Control), and the only mention is the processing above.  There is NO DOCUMENTATION ABOUT THIS (expected?) BEHAVIOR.

Does that mean that my derived class(es) must process the VK_F5 key?  Or never chain back if VK_F5? Or ???  What do other apps do?  (examples have no special processing).

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
franji1 Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 28 June 2005 Status: Offline Points: 70	Post Options Post Reply Quote franji1 Report Post Thanks(0) Quote Reply Topic: VK_F5 behavior CXTPReportInplaceEdit::OnKeyDown Posted: 22 April 2022 at 9:26am
	XTP V13.2.1 I am chaining back my calls to OnKeyDown when I am not processing them. The tookit behavior process the F5 key from within my edit control of an item to call the report control's Recalc method: _pControl->Recalc(TRUE); which immediately calls EditItem(NULL), which currently deletes my edit control. Hence, when I return back, my edit control is GONE - window handles are 0xdddddddd, etc. So MY code ends up crashing (asserting) because my object thinks it's still around (which it is not because of the call to EditItem(NULL)). What is the expected behavior of F5 when editing an item in a report control? I search the source code for VK_F5 within the entire XTP toolkit (not just Report Control), and the only mention is the processing above. There is NO DOCUMENTATION ABOUT THIS (expected?) BEHAVIOR. Does that mean that my derived class(es) must process the VK_F5 key? Or never chain back if VK_F5? Or ??? What do other apps do? (examples have no special processing).