BKeeney Shorts Progress

picAppIcon256It’s been a little over a month since BKeeney Shorts, our Real Studio/Xojo reporting classes, were released to the general public.  All I can say is thank you!  The response has been tremendous and has exceeded my wildest explanations.

We’ve been working on a few updates this week.  First, we can now search a report for specific instances of a string.  This wasn’t on our radar but during the Xojo Developers Conference someone blurted it out during our training day and it got me thinking.  It turns out it was really easy to implement.

One of the things that Shorts does is has all of the pages available to the document and all of the objects on the page available to search so it ended up being an incredibly easy thing to do.  We don’t really ‘render’ the page until it’s called for.  In the demo app we added the search function and also created a list to show which pages the instance is on.  I think you’ll be really happy with it.

The second thing we accomplished this week was to get RTF Text blocks mostly working.  RTF is a particularly troublesome format to deal with because you have to convert from RTF into something that Xojo understands (StyledText) and then figure out how to draw it because we can’t use the standard TextArea.DrawInto command because our Page display can zoom in and out and also deal with Retina display on Mac OS X.  What a pain and I’ve already been able to get it to fail if I make the RTF even remotely complicated.

The conversion to HTML and PDF has gone relatively smooth but there are some minor glitches to work out there too.  Few conversions are 100% perfect and the trick is to get it close enough so most people are happy with it (or at least don’t send angry emails).

So what else is coming up?  That’s always a tough question to answer.  One of the things we really need to get into the product is automatic text block height calculations.  You provide the string, block width, and characteristics and it returns the height.  You can do this on your own now but it’s not nearly as easy as it could be.

The second thing that I really think would be cool for a Xojo application is runtime interaction with your report and receive events when a user clicks on a report object.  Imagine if you will an account balance report.  You see that account 10100 has an unusually high balance and rather than go back to the report screen to create a report on that account you simply click on the account.  The Shorts viewer receives an event, and the smart developer responds to the event and automatically creates a drill down report on account 10100.  I know of no other reporting tool in the Xojo world that is doing that.

Then there are some of the obvious needs.  We really want to add a designer control allowing you to visually create reports and then save that format into an external file so that in the long run reports don’t have to be compiled into your application.  Client wants a tweak to a report?  Find, send them the new report definition file and voila, it’s done.

I’m sure I can come up with a half a dozen other things I want to see in the product.

Some of the comments we’ve received about BKeeney Shorts so far have been awesome.  Things like it being easy to import into an existing project, fast in creating reports (about 300 pages a second!), and thanking us for wonderful support are all really cool things to get in your email in box.

That’s my quick update for BKeeney Shorts.  What sorts of things do you want to see in a reporting tool for Xojo?

8 thoughts on “BKeeney Shorts Progress

  1. Oh my. Reporting/reports are hard work. Good on for working this problem. The people who thought up rtf should be spanked

  2. This is very interesting to me. I’ll be keeping up with your progress. I was looking down the road at needing to produce 10-100 page reports within my software and.. well.. I was dreading it a bit. I assumed I’d use my DynaPDF license, so it’s very cool that you incorporate it. Thanks for the update, Bob!

  3. We made a lot of progress on the RTF integration this morning. After banging my head against it for quite a while we decided to use a stripped down version of the Formatted Text Control and let it do all the work. It made sense because a) it already converts from RTF and draws to a canvas object and b) we own it and maintain it.

    We’ve stripped it of much of its events and other handling and so far it’s pretty fast. I have a lot more testing to do but it seems okay. The trick will be documenting it so that Web Edition users don’t add it to their project because it just won’t compile with some weird error messages.

  4. @Jason Adams
    No real limits other than that for Desktop apps we’re using stripped down portions of the FTC to do some of the RTF rendering. For Web Apps we’re converting to HTML to display page by page and you can always generate the entire PDF and have that available for viewing (on html5 capable browsers) or for download.

    The one thing we want to avoid is have developers be confused on why it won’t compile for Web Edition if they leave the RTF code for desktop (i.e the FTC code) in the project. Not having support emails is a really good thing. 😛

  5. @Bob Keeney
    Right, I see. You could always make specific methods Desktop/WE specific… But I’m sure you’ve already thought of this. I’ll just let you do your work and buy it when I’m ready for it. 🙂

    I’ll try avoid support emails. Blog posts, I’m sure, are infinitely better. 😉

Comments are closed.