Shorts Report Designer 1.6.1

pens128BKeeney Software is proud to announce Version 1.6.1 of BKS Shorts with Report Designer, our reporting classes and tool for Xojo.  Shorts allows you to integrate a report designer into your own Xojo desktop application.  Desktop and Web applications can generate reports.  Both versions can export to PDF if they have the MonkeyBread DynaPDF plugin.

This is a free update to all existing users.  This version is mostly a bug fix release and is recommended for all users.

Change List:

  • The Footer Constants can now also be used in the header
  • Refactored DesignCanvas and ReportPF and moved some of that code into PAF_DatabaseKit.DBWrapper where it makes more sense
  • Loading a report into the designer, or for rendering, will no longer re-read the schema and overwrite any manually created relationships
  • Added Tables and Views section into the report definition file
  • Fixed an issue with report width/height not being remembered correctly. Changed from using PrinterSetup string which is not cross platform safe to use the dimentions instead.
    • YOU NEED TO RESAVE YOUR REPORTS TO TAKE ADVANTAGE OF CHANGE
  • Fixed issue where landscape reports weren’t being exported properly to HTML and PDF.
  • Added breaks in the PreparedStatement creation to help in debugging.
  • Added some missing field handling to ODBC
  • DBWrapper will no longer create a missing SQLite Database.
  • Fixed UI in winDBRelations

ISA and Casting

One of the things that’s just not talked about much in the Xojo documentation unless you know where it is located is object casting.  ISA and Casting is so useful it’s worth devoting some time talking about it.

Let’s start with some common examples in desktop applications.  We all use the Window class.  Typically our new projects start with an instance of the Window class called Window1.  To put it another way, the Superclass of Window1 is Window.

The ImplicitInstance property of windows is subtly evil.  Subtle because if you reference anything in Window1 it gets created if it’s not already.  A lot of new Xojo developers will ask how can they tell if a window is open or not.  They’ll often come up with something like this:

if window1.visible then return true

If window1 is not open this line will actually create it!  So this is a bad thing and why I recommend that you turn off ImplicitInstance on all windows until you understand the implications.  I digress.

The better way to tell if an instance of Window1 is open is to iterate through global Window method.  You can do that by doing something like this:

for i as integer = windowcount-1 downto 0
   
   dim w as window = window(i)
   
next

This will iterate through every window, visible or not, that the application has created.  I used DownTo because many times you want to close said window and going UP will cause funky things to happen to your array of windows (I will leave this as an exercise for yourself).

If you put a public property in Window1, say, s as string.  You cannot do the following:

  for i as integer = windowcount-1 downto 0

dim w as window = window(i)

if w = window1 then
   
   w.s = "this is text"
   
end

next

The compiler will squawk with an error:  Type “Window” has no member names “s”.  This might seem mysterious, but the window returned from the Window array is a Window, not the subclass window1.  It’s an important difference.  The framework call to Window brings back a listing of all Windows even though each individual window brought back will be a subclass.  The array must all be of the same class type (Window) for it to work so the framework uses the Super.  To work with the Window1 properties you have to cast the window returned to an instance of Window1.

If you only have one window type (highly unlikely in a real app) you could simply cast any windows to window1 but that’s unrealistic.  Instead, you need to check what type it is first.  Using the ISA operator you can test what kind of window subclass it is.  If w is an instance of Window1 than you can do something with it.

  for i as integer = windowcount-1 downto 0

dim w as window = window(i)

if w isa window1 then
   
   //Do something here
   
end

next

The next step is to cast the window to the subclass.  This is as simple as wrapping the window variable, in this case w, with the name of the subclass, Window1.

  for i as integer = windowcount-1 downto 0

dim w as window = window(i)

if w isa window1 then
   
   window1(w).s = "Some Text"
   
end

next

If your code is wrong, or you try to cast it the wrong window type you’ll generate an exception at runtime that says Window1 cannot be cast to whatever the object you’ve put in.  For example, the following code generates that error:

  for i as integer = windowcount-1 downto 0

dim w as window = window(i)

if w isa window1 then
   
   window2(w).s = "Some Text"
   
end

next

This type of paradigm is common throughout Xojo.  We already know about the Window and WindowCount methods.  Another commonly used one is the Control and ControlCount on a Window.  Code like this happens quite a bit:

  for i as integer = 0 to ControlCount-1

dim c as control = control(i)

RectControl(c).Visible = False

next

This works fine as long as your control is actually a RectControl.  Not all items returned by the controls method are RectControls. Checking with the ISA operator before casting is important.

The ISA function and Casting can be an important tool in your application.  It can take what would be some tricky Introspection and turns it into a trivial piece of code.  It’s also one of those things that you don’t know you need it until you need it.

We Are Part of the Problem

For some users, Xojo 2016 R1 hasn’t been a great release.  Some Windows users are experiencing frequent crashes.  For others (myself included), working in the WebPage Layout Editor is an exercise in frustration because it’s unusably slow.  We blame Xojo, but we, the beta testers, are culpable for these problems as well.

Before you start angrily sending in comments hold your horses.  R1 had a really long beta cycle.  Clearly, Xojo had issues with figuring out HiDPI for Windows and their work isn’t finished yet (hence the beta tag for HiDPI in Windows).  It happens and some times you have to ship an imperfect product.  We always have the option of NOT using the latest version of the product.

Some will say that Xojo shouldn’t have released R1 in the state that the Windows version was in.  That’s only partially true.  Xojo uses their own product all day long to create their product.  They, more than many of us, see the warts in their product and I know they try really hard to eliminate as many of those as possible.  But they use it differently than we do so I wouldn’t expect them to find every bug.  That’s where we come in.

The beta program exists so we can bang on the product using our own real-world projects.  It’s up to us to find and report the fringe cases and use the product in different ways that what the IDE expects.  I know that in this beta cycle I was swamped with consulting work so I only fired the betas up occasionally.  So whatever problems there is on me and on everyone else in the beta program that didn’t test.

I will grant you that the only incentive we have for participating in the beta program is a less buggy product.  For some that’s enough but when you’re busy trying to get your own products out the door there’s not much incentive to work even more and find bugs for someone else.  In my opinion, this has always been the problem with the beta program.

Some of use are also guilty of not starting testing until the Final Candidate releases.  This is actually the worst time to start testing because it means only show-stopper bugs will get fixed.  We really need to start testing with the early beta’s.  That’s when Xojo needs us the most to bang on their product.  Is it fun?  No.  Is it necessary? You bet because waiting until Final Candidate is worthless to them.  To us too, because those bugs might not get fixed for 3 months.

Did Xojo help us out in this cycle?  No.  There were times they were putting out a new beta every day.  Sometimes with only a couple of changes from the previous version.  I would download a beta with the intention of working with it and before I could get to it a new beta would be announced in the next couple of days.

I don’t know about the rest of the people in the beta program, but the high frequency of beta releases meant I looked at them less.  I don’t know why but it was.  I saw the announcements rolling in and I shrugged in apathy.  Perhaps I felt the frequent releases didn’t properly value my time.  I only have so much time to devote to beta testing and the frequency was off-putting.  I like to use a version for 3 or 4 days (or until I find a major bug a report it).  With so many releases I just didn’t test.

I propose that with the next cycle Xojo limit their public builds to once a week (maybe a Thursday or Friday release).  This respects my time a bit more since my only incentive is to make it a better product.  Frequent public releases says that they’ve not vetting their product enough before giving it to us.

I also think there needs to be something in place that identifies what type of beta tester we are.  Are you mostly a Windows user?  Then Windows specific changes get highlighted for you because you’ll be most likely to see them.  Same with Mac OS X, iOS, and Linux users.  Desktop, console, and web app users might also be a designation.  I realize this doesn’t fit in with the current generic “hey, we have a new beta” announcement.  But it’s clear from R1 that the generic approach didn’t work.

We have too many major bugs in this last release to call the beta program a success.  It’s not doing what we need it to do.  So how do we structure is to so that our time is respected and we actually report bugs before Final Candidate stage?

What about you?  What suggestions do you have to help us and Xojo out at the same time?

Xojo 2016 Release 1

Xojo 2016 Release 1 was released today.  This much anticipated version is all about Retina and HiDPI display support.  In addition to that, there are, as always, the usual mix of new features and bug fixes.  Let’s get to it!

The IDE is Retina Aware

The IDE itself is now Retina capable and all of the icons and images used in the IDE have been replaced with high resolution images.  On my 27 inch 5k iMac it’s quite a noticeable difference to my aging eyes: everything is very sharp.  As with many apps once you start using the high resolution version it’s hard to go back to a lower resolution.

Before you jump into this version you might want to do some testing.  On relatively new iMac the Web Layout Editor is very slow.  So slow as to be almost unusable.  This only happens on existing projects since new projects seem to work just fine.  Perhaps it’s a combination of project size and/or web page complexity or number of Web Containers.  I really don’t know but I’ve submitted a Feedback report showing the symptom and an application sample from Activity Monitor.

Your Apps Can Be Retina Aware

In the last Xojo version we were introduced to ImageSets and that feature is now more useful in 2016 Release 1.  The ImageSet allows you to add a normal sized image (1x), a 2x image, and also a 3x image.  Mac OS X only uses the 1x and 2x images but some Windows 10 resolutions will use the 3x image.

HiDPI support for Windows is officially beta and I believe that’s mostly because the various versions of Windows that Xojo supports all do HiDPI slightly different.   Currently Xojo does not support Window 10’s per-display scale factor and will use the scale factor of the screen it was launched on.  TextArea’s only display in large size, the HTMLViewer and MediaPlayer is not scaled, BevelButtons don’t display, and Image Set Icons do not appear correctly in toolbars.  Obviously this is less than ideal for Windows applications and you probably don’t want to release a Windows app with this set.

With Retina/HiDPI support is a new Application shared property called SupportHiDPI.  When set to true, Xojo will build your application with Retina and HiDPI awareness.  When set to false it will build apps that worked the same was as previous builds.  Sadly, this property cannot be changed at runtime because it would make enabling it for Mac OS X a no brainer but leaving Windows as is.

As you can imagine, Retina/HiDPI changes a number of important things.  The Picture class has a new constructor that can take one or more bitmaps in addition to its size.  All bitmaps must have the same aspect ratio or an invalid argument exception is generated.  One question that I’ve not explored for myself is how exact this ratio must match.  What is the precision on this check?

The graphics object now has a ScaleX and ScaleY property.  For pictures the scaleX/Y are always set to 1, but a graphics object passed in from the paint event might have a ScaleX/Y set to 2 on a Retina display.  Graphics.Pixel is now deprecated (NOT REMOVED).

Windows have a couple of changes too.  There is a new event ScaleFactorChanged on Mac OS X that is an indicator that all graphics for that Window should be invalidated.  A read only ScaleFactor tells you what the scale factor is for this window.  The Canvas object has a similar ScaleFactorChanged event on Mac OS X as well.

Local Language Reference

Retina is not the only new thing in R1.  The Local Language Reference has been revamped again and if you are a Dash user you’ll notice that it shares much of the same look and feel.  Searching for an item in the Language Reference, in my opinion, is considerably easier in this new version and I find I like it better than the online version.  Besides being able to search for any event, property, class, enum, etc the local language reference allows you to go back through your search history rather quickly.

Web Framework Changes

The web framework received a number of important changes.  Perhaps the biggest and most important to web users are that WebStyles have changes their implementation.  The change notes say “User defined WebStyles now have more specificity than framework applied styles.” which I have been lead to believe means that WebStyles now work properly in all cases as there were fringe cases where styles were either ignored or improperly applied.  During the beta cycle Xojo asked us to test web apps to make sure nothing broke.  In my testing I didn’t see any issues.

The connection type of a web app can now be set with a command line option.  The WebListBox received some love too.

Miscellaneous Fixes

  • Build times have been improved.
  • Xojo.net.httpsocket now works in Mac OS X console and web applications.
  • A memory leak in NSWindow was fixed in the Cocoa framework.
  • The FileTypes editor has received a number of bug fixes and changes.
  • 40 changes to the documentation and examples.

Conclusions

With all of this work on Retina/HiDPI applications for Release 1 I am disappointed at the lack of project examples for HiDPI and Retina.  Sure, the SupportHiDPI is an easy thing to do, but for many of our applications that create images on the fly we are only left with some fairly vague instructions.  A Xojo Blog posted today http://blog.xojo.com/a-journey-of-a-thousand-pixels might be your best bet in understanding some of these changes in more detail but even I scratched my head with some of the implementation details.  Actual example code that show the practical implications of Retina/HiDPI and creating images would have been very welcome.

I’m relatively happy with 2016 Release 1 though not without some reservations.  Since the number of Windows controls in HiDPI that don’t scale properly is fairly large it’s not ideal that you can’t turn off HiDPI for Windows but keep Retina on for Mac OS X.  Sure, you can always do two builds but it’s not an automated option.  Performance issues with the Web Page Editor is also troubling and perhaps this means there’s a dot release in our near future.

There are quite a few things on the horizon that Xojo needs to tackle.  Full debugging in 64 bit and a 64 bit IDE is perhaps the biggest one and the HiDPI stuff is surely a distraction from that important requirement.  This beta cycle was really long and it makes you wonder how much their schedule has shifted just to get HiDPI (mostly) working with some obvious work still to do.

What are your thoughts on Release 1?

Shorts Report Designer Release 1.6.0

pens128

BKeeney Software is proud to announce Version 1.6.0 of BKS Shorts with Report Designer, our reporting classes and tool for Xojo.  Shorts allows you to integrate a report designer into your own Xojo desktop application.  Desktop and Web applications can generate reports.  Both versions can export to PDF if they have the MonkeyBread DynaPDF plugin.

This is a recommended update for all registered users and is a free upgrade.  Besides a number of important bug fixes there are also some big new features

Runtime DateTimeThe first is the ability to ask the user for runtime parameters for a query.  For example, if you created a report based on a fiscal year you can now ask the user which fiscal year they want.  The dynamic runtime query lets you ask the user for a number of different things.  Strings, numbers, user supplied lists, and even a list based on a database query are possible.
Drilldown EventThe second thing we added is the ability to get an event back from the generated report on what row was clicked.  This event gives you the information for all objects in that row so you could implement a drill-down report.  Along with this event we now allow invisible objects to be created to provide additional information.

Our product page is at http://www.bkeeney.com/allproducts/bkeeney-shorts/

Full change list:

• Dynamic Runtime Query variables. Allows the report designer to ask the user what values they want at runtime. Current paramters types::
– Boolean value using a Checkbox
– String value
– Numeric (integer and double values)
– User List (popup)
– Query List (popup)
– Date, DateTime, or Time

• Moving items via the mouse will immediately update the save status on the Toolbar

• Changing Filter Data will update the save status and undo status

• Undo now works for changing of filter data.

• Added Filter Data to report designer Toolbar

• Added an ObjectSelected event on the BKS_ShortsBaseViewer that will pass back the clicked BKS_Shorts.Item and if there is one, the BKS_Shorts.GroupItem. This will allow you to implement a drill down report.

• Invisible TextItems are rendered in the background color to allow the MouseHit to bring back additional information in the group

• Added a FieldName property to BKS_Shorts.Item and reports run through the Report Designer will fill that in at generation time. This allows the user to query what the field (if there is one) from the selected item.

• Added OK/Cancel generic container for all dialogs

• Bug Fix [Windows Only]: Now respect the number of copies specified for a print. Note that this is not in Shorts classes itself but how the supporting code prints.

• Bug Fix: Fixed another instance where it was possible to NOT have a Default Style when generating a report.

• Improved German localizations.

• Moved About Shorts Designer Menu Item out of winReportDesigner

• Bands that are marked as invisible no longer get rendered on the report.
Known Limitations:
• Dynamic Queries do not work with IN clause in where statements.

XDC 2016 Sessions Announced

Xojo announced an initial session list for XDC 2016.  The full list at http://xojo.com/xdc/HTML/sessions.html.  I’ve been told there are yet more sessions to be announced.

I’m doing a session on Reporting in Xojo and Carol is doing a session on eliminating common database mistakes.  Since we do a lot of database applications with reporting I think you’ll like our insights, processes and solutions.

I am impressed with the number of new speakers and the topics that have never been done before at XDC.  Want to learn more about developing iOS or Raspberry Pi applications with Xojo?  There are sessions on that.  Want to learn about REST web services or how to creating web API’s with Xojo?  There are sessions for those as well.

XDC is where you go to immerse yourself in Xojo for three days.  Since we are a smallish community we don’t often talk to other Xojo developers face-to-face.  XDC is where you will meet not only those that inhabit the forums but also the engineers behind Xojo.  This is the only place where you will find out about upcoming changes and additions to Xojo.

Last year Xojo recorded all of the sessions and those are available in the web store ($499).  I’ve not heard if they will record this years events but I found the recordings to be very useful because you can’t make every session.

They made this promotional video last year.  I think it’s pretty good so I’ll just let it speak for itself. I have a cameo at 1:47 or so.

Today is the first registration deadline and they are already sold half of the available spots.  More info at http://xojo.com/xdc/HTML/index.html.  Hope to see you there!

Microsoft Buys Xamarin and SQL Server Goes Cross-Platform

It’s been an interesting couple of weeks in the cross-platform development world.  First, Microsoft announced that they were purchasing Xamarin.  Xamarin and Microsoft have always been friendly and this move isn’t very surprising.  As a Mac user much of the marketing verbiage doesn’t talk about the Macintosh, just iOS along with Android and Windows Phone and Windows apps.  Xamarin has always seemed to be mobile first and desktop last, so again, this doesn’t seem surprising.

Many people really like Xamarin and there are a number of Xojo developers that have tried it out.  Their opinion of Xamarin isn’t very good:  limited support, expensive, buggy IDE, and slow building of apps are just a few of the major complaints.  In comparison Xojo, they say, is ‘fast and lean’.

This week Microsoft announced that SQL Server, their Windows-only database server will be ported to Linux and be available in 2017.  This seems to be a tacit agreement that their biggest weakness in the server world is Linux.  Linux is extremely popular and since it’s cheaper to deploy than Windows they have to do something to stop the hemorrhaging.  Perhaps they’ll sell a boatload of licenses but it’s tough competing against the free or inexpensive database servers like PostgreSQL.  Again, no where are they talking Macintosh OS X.

This news makes me happy that cross-platform app development is getting some attention.  When the big boys of the world are pumping money into it then there must be something to it.

It also makes me sad since I don’t see Xojo changing their focus.  For many years they have had this hobbyist/part-time developer first mentality.  This has hurt them with professionals looking for a new development tool.  There are many things, I believe, that hurt them in this market.  I’ll list a few here:

  • It’s a BASIC language:  No getting around it.  It’s a modern object oriented language that compiles down to native code, and (mostly) uses native controls doesn’t seem to matter much.  VB6 screwed up many peoples opinions of language for better or worse.  In reality, there are lots of really good VB6 apps out there but many more poor VB6 programmers.
  • The IDE: especially the Code Editor.  It doesn’t let you do bad things and that’s great for beginners.  Usually it’s the first thing people complain about, though.  It’s limiting, and forces you into the Xojo way of doing things.  No other major IDE, that I’m aware of, forces this restriction upon their users.
  • Lack of basic controls:  I’ve been using Xojo for 15 years and have a tool chest of controls and libraries that I use on a daily basis.  But still, the lack of even basic Date/Calendar controls is a turn off for many first-time users.  Add in very poor RTF support, no PDF support, and especially no true grid control and you have a lot of strikes against the tool.  Yes, you can turn to the 3rd party community for some of these (and they are not very expensive) but to not have any of these things hampers adoption.
  • Reporting:  I don’t know of any serious Xojo developer using the built-in reporting tool.  It’s just not robust enough for most peoples needs.  We’ve used several 3rd party tools over the years and in the long run wrote our own (BKS Shorts).
  • Android:  iOS was a big addition to Xojo but without Android it’s not convenient to do a lot of mobile development with Xojo.  To add Android is a huge project and unlike anything they’ve done to date.  I would expect a minimum of eighteen months but probably more like two years of major development work to get it into Xojo even as a beta.  And that’s assuming they announce it.

I use Xojo all day every day and use it for dozens of commercial desktop applications and dozens of Xojo driven web apps.  Xojo is mostly stable and under constant development.  Just in the past year they’ve added iOS and Raspberry Pi development as well as added 64 bit compiling for Mac OS X, Windows, and Linux.  Much of the limitations you can overcome by dipping your toes into the 3rd party market – but that market is tiny in comparison to many other development tools.

So my wish is that Xojo would focus more on business needs.  Identify the features that business owners need and implement them.  Include more basic controls and charge more for advanced controls that not every developer will need.  Get reporting cleaned up.  Make database programming smarter and less error prone.

It is my firm belief that if you get the business users you’ll capture the part-time and hobbyist programmers along the way.  Many of the hobbyist and part-timers only care about one platform and that’s only a $99/year investment.  If you want to do cross-platform desktop that’s only that’s $299/year.  For every desktop license you need three single licenses.

A Pro user like myself needs desktop, web, and console apps for sure.  iOS is a nice add-on but not necessary for us at this point.  The Pro license costs $699/year.  You need seven single licenses to make up for it.  My company has four licenses and we renew every year.  So my business is the equivalent of twenty-eight single license users and while I might grumble at writing a check every year for license updates it’s nothing at what we used to pay for VB6 and 3rd party licenses every year.  At one point it was $2,000 per developer per year.  That’s just the price of doing business.

So tell me, which type of customer should Xojo focus on?  What do you think their biggest weakness is in capturing some of this nascent cross-platform market?

Imposter Syndrome

Today I’m going to talk about the Imposter Syndrome.  That feeling that says everyone knows you’re faking it and they’re going to find out, at any minute, that you’re a fraud.  You’ll be cast down into the depths of despair in humiliation because EVERYONE WILL KNOW YOU SUCK!

I’ve experienced this feeling and I’ve had conversations with developers I greatly admire that struggle with this too.  This is both heartening because it means we’re not alone in this despair, but it’s also sad since that means there’s really not a point where you’ve ‘made it.’
Feeling like an imposter doesn’t go away as you gain experience but it’s not as big a deal.  With more experience you know the things you know and have hopefully gained enough knowledge and wisdom to know where to start looking for the things you don’t know.  Still, sometimes, you have to fake it.

Wait, fake it?  Yes.  Sometimes you have to be an imposter.  Let me use a poor analogy to explain it a bit more.

When you start a new video game you just start playing, right?  You know a few rules and as you progress you make mistakes.  You learn from them and at some point you level up.  This comes with a fancy cut scene showing your character victorious over the foe, gaining an object of some value, and gaining experience.  Your character is more wise and capable of doing more things.  You were up for the challenge and overcame the barriers to the next level.LevelUp

Being a consultant and software developer is no different than a video game.  You have to play the game to learn the rules.  The consequences of not learning the rules can be disastrous but hopefully you’ve done your research so those rules don’t kill you (metaphorically speaking, of course).

At some point you level up from time and experience doing consulting and programming projects.  Sadly, there is no amazing cut scene with dramatic music since we rarely, if ever, see the level up process.  It’s shame really because I’d really like to have dramatic music just play from nowhere and obtain some cool device from my endeavors.  But I digress.

For a Xojo consultant, like myself, it’s knowing parts of the framework really well and realizing that I don’t know some parts as well.  I do a ton of small example projects to learn those bits better.  It means creating my own tools to make my daily life easier.  Those tools involve ActiveRecord, and Shorts to name a few.  These were not developed overnight but over the period of a decade.

So the next time you feel the Imposter Syndrome hitting, recognize that it’s a natural part of the process.  You leveled up without noticing and that’s okay.  You can handle it.  It means you’re winning.

Upcoming Xojo Events

Next Wednesday, February 24th, I will be meeting with Xojo developers in the Palm Coast, Florida area. The location isn’t set yet, so check in the forums at https://forum.xojo.com/28686-central-florida-xojo-user-group and let us know if you can make it. We’re getting together at 7 PM and I hope to see you there!

March 11th, 2016 Christian Schmitz of Monkeybread Software fame is getting tougher with other Xojo folks in Chicago, Illinois near O’Hare Airport. More information at https://forum.xojo.com/28759-xojo-meeting-for-chicago-illinois. I had originally hoped to make this meeting and offer some training but I already had a commitment.

March 15th, 2016, Christian Schmitz is in Cleveland, Ohio. More information at https://forum.xojo.com/28758-xojo-meeting-for-cleveland-ohio

Monkeybread Software is hosting an event in Koblenz, Germany on May 19 and 20, 2016. Two Xojo representatives will be there for this two day event. I went to one of these events a couple of years ago and had a really good time. The Xojo conference was fun and the day after the event a number of us went on a tour along the Rhine River Valley. Fun had by all! More information at http://www.monkeybreadsoftware.de/xojo/events/koblenz-2016-event.shtml

The big Xojo event of the year is October 5-7, 2016 in Houston, Texas. The Xojo Developers Conference (XDC) will have twenty-eight speakers, thirty-five sessions, and attendees from around fifteen countries. The entire Xojo development team will be there and what’s discussed at meals and events is just as important as the sessions. It’s not an inexpensive event, but if you want to learn more about Xojo and pick the brains of Xojo experts, XDC is THE event to go to. More info at http://xojo.com/xdc/HTML/index.html.

Getting together with other Xojo developers is a lot of fun.  I highly encourage you to find other developers in your area and start sharing the knowledge!

Shorts Report Designer Release 1.5.4

pens128We released version 1.5.4 of the Report Designer today.  One of the bigger changes is it ships with a web example of how to take a report definition and display it for a web app.  This affects a significant amount of methods and properties throughout the project to make them work on desktop and web but seems to work well.

BKeeney Shorts (with report designer) is 100% Xojo code (DynaPDF Starter kit required to export to PDF) and comes with a drop in Report Designer and Report Viewer component for both desktop and web apps.

For purchasing information please visit http://www.bkeeney.com/allproducts/bkeeney-shorts/

Version 1.5.4 change list:

  • Major code changes to allow most classes to work in web apps too.
    • Simply copy BKS_Shorts_ReportDesigner folder into your existing web project.
    • Delete PAF_PrintKit.DesignCanvas (desktop ScrollCanvas subclass)
    • Create a new PAF_PrintKit.DesignCanvas that is a WebCanvas subclass
  • Changing text values in the Properties List is now Case Sensitive
  • Added Portugese Localization
  • Added a commented out example of how to connect to MySQL without using the winDBConnection Window.
    • See winRPTViewer.Display
  • Fixed an issue that would cause the SQL statement to not be saved properly in the JSON string
  • Added a Default Style if none is in the local dictionary
  • How reports are saved so they can be viewed without first having to be in the designer
    • WARNING! YOU WILL NEED TO RESAVE ALL OF YOUR REPORTS
  • Cleaned up some localizations and made some more strings dynamic.
  • Made the Report Designer the default pushbutton in Demo Window
  • New Report opens a new Report Designer Window instead of copying the current connection. (this affected menu handlers in odd ways one wouldn’t expect)
  • Created a Web Example