Codejock Forums Homepage
Forum Home Forum Home > Codejock Products > Visual C++ MFC > Report Control
  New Posts New Posts RSS Feed - VK_F5 behavior CXTPReportInplaceEdit::OnKeyDown
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

VK_F5 behavior CXTPReportInplaceEdit::OnKeyDown

 Post Reply Post Reply
Author
Message
franji1 View Drop Down
Groupie
Groupie
Avatar

Joined: 28 June 2005
Status: Offline
Points: 56
Post Options Post Options   Thanks (0) Thanks(0)   Quote franji1 Quote  Post ReplyReply Direct Link To This Post 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).
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.04
Copyright ©2001-2021 Web Wiz Ltd.

This page was generated in 0.063 seconds.