Windows Printing Broken in Xojo R4

We’ve done a lot more testing with Shorts and R4.1 this week.  Wow.  Where to begin.  I guess the first thing to say is if you need to print in Windows stick with Xojo Release 3 for now.  R4, with its switch to Direct2D has completely messed up printing.

Using Shorts, and Xojo R3 this is what a normal print looks like.  (Forget about the colors and stuff, I’m testing things out and the ugly colored blocks help).  Looks like it should:

Exact same code in 2016 R4.1 and this is what it looks like.  Note:  the picture makes it worse than it is, it’s not slanted like that on the page, my camera angle is just weird.  But, you can clearly see that while the lines and rectangles printed properly, there’s no text!

It’s obvious that the Direct2D from GDI+ in R4 were not properly tested.  Part of that is on us, the beta test community, but it seems, to me at least, that Xojo didn’t do enough vetting themselves.

The good news is that the Shorts display works fine as well the output to PDF.  So if you don’t actually print directly from your Shorts application you’ll be okay.

I expect better of Xojo.

18 thoughts on “Windows Printing Broken in Xojo R4

  1. “I expect better of Xojo.”

    Put the blame where it belongs: the Rapid Release Model.

    On leaving school in 1983 I had a long argument with a friend about biotechnology and the rise of antibiotic resistance. It was obvious for anybody with even a rudimentary understanding of evolution.

    The same is true for the current state of Xojo. New features (incomplete or broken as they may be) over stability and reliability leads to long-term decline.
    It was easy to see the moment they introduced the RRM.

    • Blaming the Rapid Release Model is simply BS and I’ll tell you why. Before RRM they did one or two big releases a year with dot releases in between. Bugs still go through then too.

      Look, bugs happen. No software is immune to it. What hurts with Xojo is that a bug like this affects *our* software too. Our remedy is to keep using R3 until it’s fixed.

      • You let ideology get the better of you. Under the old model you had a release and a year or more of bug fixes. You ended up with a fairly stable and functional version.

        Bug free? Of course not. But all the major bugs were gone.

        Unter the RRM each of the last five or six versions still has major bugs while Xojo simply moved on to the next version, and you need to consider carefully which version to use for which project.

        Good for Xojo, not so good for the user.

        In effect you end up paying for a perpetual beta. Not release quality.

        While some developers salivate at the prospect of new features, others prefer a rock solid tool.

        And BS? Now THAT’S what I call a good argument ;-P… but are you really trying to tell me you believe introducing new features and releasing every 3 months is not to blame for the major bugs we are seeing in release versions? You really believe those releases were release quality? Looking over the last 10 years you do not recognize a decline in quality?

        I’m not saying Xojo Inc isn’t doing a good job in developing Xojo, or the engineers are not hard-working talented people. I’m saying the RRM results in beta quality software. Your own warning (not the first either) at the top of this page would indicate I’m right.

        I would say “let’s behave like adults” but then kids only throw stones, adults go to War, so maybe I’ll better let that one go.

        • The old model had huge gaping bugs you could drive a truck through. There were new features that got released with great fanfare only to find upon inspection they didn’t work. I remember quite clearly because it was then that I decided to become a beta tester.

          Look, I understand your opinion, I just disagree. You want every release to be perfect and never change. So given your logic Xojo is damned if they advance the product and damned if they keep it perfect.

      • “Look, bugs happen.” Yes, it is true, but the question is, how many bugs are acceptable in a serious development tool?
        I had just completed my first whole year with the Xojo and Xojo is a great promise, and an interesting concept, but with so many bugs and errors, and the IDE is so hopelessly slow all the time…. it is not so easy to trust in Xojo. I wait always for the next release and hope that a miracle happens, but new release, new bugs, and the reliability is continously poor.

  2. While I use the betas regular as my main version and work with real projects with them, it just didn’t happen for me in the whole beta time, that I didn’t try printing on Windows. None of the current projects does it. So sorry, I didn’t see it.
    And I think the DirectDraw part is not finished, as I run in a couple of picture related problems with plugins. So let’s hope those get quickly fixed for 2017r1.

    • Same here. We just didn’t have time this beta cycle. It’s the curse of being busy with consulting work and having new family members being born. Good problems to have, but I wish I had taken the time out to test printing.

      Oh well, now we know better.

  3. I may be a bit biased, because in my other job I work in quality mangement, but:
    Delivering software which does not work correctly will bring you a bad reputation in a very short time. On the other side, it is quite hard and it takes a long time to build up a reputation as being trustworthy and reliable. Because of this I think delivering quality is way more important than delivering quantity (in the long term). I think that is the only sure way to find and keep loyal customers.
    I really like Xojo and I think it is one of the best cross-platform tools available. I did a couple of projects with Xojo which I could not have done with other tools. If I had one wish for free, I would wish Xojo would focus more on quality/reliability (= fixing bugs, and fixing them faster) than quantitiy (adding new features) in the future.

    • Most releases are 85%+ bug fixes. But I wish that every other release had new features in it. In 2016 R1 was good, R2 had serious bugs, R3 was decent, and R4 isn’t very good in Windows.

      Here’s to hoping 2017 is better.

  4. From the release notes for the past year

    2016r4.1 contained 11 Bug Fixes and 1 Change

    2016r4 contained 130 Bug Fixes, 24 Changes, 9 New Items
    Plus 19 updates/additions/corrections to Docs and Examples

    2016r3 contained 64 Bug Fixes, 28 Changes, 11 New Items
    Plus 13 updates/additions/corrections to Docs and Examples

    2016r2.1 contained 22 Bug Fixes and 2 Changes

    2016r2 contained 153 Bug Fixes, 22 Changes, 19 New Items
    Plus 26 updates/additions/corrections to Docs and Examples

    2016r1.1 contained 17 Bug Fixes

    2016r1 contained 97 Bug Fixes, 22 Changes, 9 New Items
    Plus 40 updates/additions/corrections to Docs and Examples

    EXCLUDING docs updates this is
    77% bug fixes
    15.5% changes
    7.5% new items

    • More interesting would be: how many serious bugs remain in each version?

      And three emergency releases in a year? You just made Christian Mezes’ point for him.

      • “Serious bugs” is a poor metric. It might be ‘serious’ to you but not for most. Likewise I might have a ‘serious’ bug that you find trivial. Some bugs you can work around and some you can’t.

        Now, I will say that ‘can’t print in Windows’ is fairly serious. That’s the kind of gaping hole that Xojo should have found in their own internal testing (I still think it’s a shame they don’t use their own @*^#$& reporting tool) and we (the beta testers) should have caught this in beta testing.

  5. I’d like to a see something like Intel with their tick-tick. Odd versions would have new features and even versions would be entirely bug fixes. Or vice-versa, I’m not married to the odd/even.

    • It’s an interesting thought. I could imagine something like this:

      Release 1. New stuff and bug fixes
      Release 2. Bug fixes only 30 to 45 days after previous release.
      Release 3. New stuff and bug fixes (90 days after previous release)
      Release 4. Bug fixes only 30 to 45 days after previous release.
      Release 5. ???? Grab bad?
      Could this sort of schedule limit the number of new things introduced each year?

  6. Maybe delivering high quality software and adding new features (at a reasonable pace) do not exclude each other. I think it is important, to never let too many known bugs accumulate. An example of 2 possible scenarios:

    Scenario a:
    Step 1) Software with new features is delivered with no known bugs (and of course a couple of new and undetected bugs).
    Step 2) Bugs are fixed as soon as they are discovered/reported. Releases with bug fixes are issued shortly after the bug was fixed.
    Step 3) Customers are satisfied, because the software does what it promised to do.
    Step 4) Because there are very few bugs to fix, developers can mainly concentrate on adding new features and testing the new features.
    Step 5) There is no deadline. The software gets delivered when it is ready (= free of known bugs).
    Step 6) GoTo Step 1)

    Scenario b:
    Step 1) Software with new features is delivered with known bugs (and a couple of new and undetected bugs).
    Step 2) Serious bugs are fixed soon after they are discovered/reported. Releases with emergency bug fixes are issued within a couple of weeks. All other bugs do not get fixed. Maybe the not so serious bugs will be fixed with the next release in a couple of months, but maybe not.
    Step 3) Many customers are not satisfied, because the software does not do what it promised to do.
    Step 4) Developers must add too many new features in a too short time. They have not enough time for testing. Some old bugs get fixed, but many bugs remain unfixed. Also some new bugs get introduced.
    Step 5) There is a tight deadline. The software must be delivered even when it is not ready (= free of known bugs).
    Step 6) GoTo Step 1)

    There are many small software companies which seem to work according to scenario a (I know because I use their software).

  7. I just reported another issue.
    In 2016r4 the GetDeviceCaps function from Windows reports physical paper size as 0/0. Works in all older versions.
    This broke our DynaPDF code to print PDFs.

Comments are closed.