When using the C++ SDK on desktop Windows is there a recommended method to draw on the main window of PDFViewCtrl (ie. the window identified by ‘PDFViewCtrl::WindowID::e_main_view’)? So, for example, if I wanted to perform rectangle rubber-banding over a PDF page in the same manner as the ‘Rectangle Selection’ standard tool (‘PDFViewCtrl::ToolMode::e_text_rect_select’) what would be the best way to do this?
I have set ‘EventHandlers’ to detect ‘mouse_left_down’ and ‘mouse_move’ (hence mouse drag) events, but I’m not sure what to do next. Is it necessary to call ‘PDFViewCtrl::Refresh()’ in the mouse move handler in order to generate an ‘on_paint’ event and then use the event’s device context pointer to draw on the window? If this is the only way will it not be hugely inefficient to repaint the PDF page on every mouse move event?
Also, on a related issue, what is the purpose of the standard tool ‘PDFViewCtrl::ToolMode::e_custom’? The purpose of the other tool modes is fairly obvious, but I’m not sure what setting ‘e_custom’ does and whether or not it might be useful for what I am trying to achieve.
The pdftron::PDF::PDFViewCtrl::PaintEvent is what you are looking for, as it provides the hDC element to write. Included in that event is the m_pdfviewctrl_processed boolean, so when that is true, PDFNet has already drawn, so you can then overlay what you want. The even also includes the window id.
Use PDFViewCtrl::SetCustomEventHandlers to register for this.
As for e_custom, you can use this to setup your own tools. If you want more then one custom tool, then simply set up your own parallel ids, and use them with e_custom.
As for general refresh, you can pass a Rect to PDFViewCtrl::Refresh so that only that area is updated.
Many thanks for your helpful reply - it confirms I’m following the ‘recommended method’ and have not missed some other approach.
I guess I can regard setting ‘ToolMode::e_custom’ as an instruction to PDFViewCtrl to do nothing with mouse events etc so that my application can handle them in order to implement my custom tool. (Setting other values of ‘ToolMode::’ cause PDFViewCtrl to handle events for rubberbanding, drawing annotations, etc.)
One final question, you say “The event also includes the window id”. I assume this is the field ‘enum WindowID m_event_window’ - is this WindowID purely an internal PDFNet ID or can it be used to obtain the actual platform specific window handle (an HWND on a Windows platform)? It would be useful to obtain an HWND in order to change the cursor bitmap when using a custom tool.
I would not count on the id matching to anything the OS knows about. If you really want to get the HWND, you would have to get it from the hDC, which I’m not sure is possible.
If you are using .Net 4, you should look at our PDFViewWPF, as this has more code exposed, and is more customizable.