Thanks as always!
..Ben
[Update]
I thought I provide a small case for this request. Suppose you develop a Quiz app that the user provides an answer to a question on page 1. Depending on the answer, the program may transfer to page 3 or 4 or 6. This way, the user is not allowed to go other pages on their own.
Thanks!
8 Answers, 1 is accepted
Currently you can handle the PreviewFlipStarted event and to cancel it by setting e.Handled=true; in the event handler.
Best wishes,
Valentin.Stoychev
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

Thanks!
..Ben
Introducing a new property(ex. AllowPageTurn) can easily be done, but then some questions might arise. Which is with greater priority - the PreviewFlipStarted event or the AllowPageTurn property? What happens if you handle the PreviewFlipStarted event and set AllowPageTurn to true? What about the other way around? This deserves deeper discussion, so I'd be glad if you can share you opinion on the subject.
Greetings,
Kiril Stanoev
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

Thank you for your thoughtful response. And you're absolutely right that it deserves a deeper discussion, because we have more than one elements that affect that decision making.
Although Valio brought it up first, but now that you brought up the combo effect, I see the point.
Here is my take at it:
a) When the AllowPageTurn is set to true, It would be exactly as it is now, which means if PreviewFlipStarted is handled, then it stop the page, which is the same as AllowTurnPage to False.
b) However, if AllowTurnPage is set to False, then it overwrites the PreviewFlipStarted event. Basically, the AllowPageTurn has the maximum power.
But This power only disables the page turn via mouse and keyboard by the user and not code turning the page.
I ultimately leave the final decision to you guys and I'm sure the decision will be the correct one like I see the rest of the controls. If you see that the addition of the property does NOT create side effects, then it would be nice to have. If not, I'll go via event handling.
But when we turn page via code, please make turn like it was done via click or keyboard.
Thanks!
Thank you for elaborating on your opinion. We'll take it into consideration the next time we work on RadBook's API. Also, thanks for pointing that some events are not fired when turning the pages programatically. I'll make sure to fix this either for this week or next week's internal build. I have also updated your Telerik points.
Regards,
Kiril Stanoev
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

I believe that events such as PreviewPageFlipStarted are now called when flipping the pages via code (either by RadBook.NextPage() or by manipulating RadBook.RightPageIndex). This means that setting e.Handled in the PreviewPageFlipStarted event will not allow page turns at all (manually or via code).
The best solution I can come up with at the present time is by setting the following properties of the book, however, if the user clicks in the very corners of a page (in the small 1x1 foldsize) they could still do it.
PageFlipMode
="None" ShowPageFold="Never" FoldSize="1,1"
Are there any other solutions to this at present?
If you want to turn the pages only from code you can set a variable that the flipping is done from code and not the set the e.Handled to True in the PreviewPageFlipStarted event.
Kind regards,
Valentin.Stoychev
the Telerik team

That will solve my issue. I'll set a flag when my next/previous button is clicked to indicate it's a code related flip and then only set e.Handled if this flag is false.
I should have thought of that. Thanks for the quick response.
Simon.