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

WebSession.Quit

For years we’ve been doing some basic checking in the WebSession.Open event of our Xojo web apps. First, we check to see how many open sessions we have and if it’s over a preset number.  The second check we do is to see how many open sessions we have for the current IP address. We set it to something low like 10 because when some joker decided a few years ago to prove that Xojo web apps suck. He opened up our training app, and then hit refresh 150 times and then complained about how unresponsive the app was (thus proving his point that Xojo web apps suck, I guess).

In our apps, if either of those conditions is met we use a ShowURL to redirect to one of the webpages on our regular website to show the user that the app is either too busy or something bad happened. It’s worked decent enough that I’ve never revisited it until this past weekend when several users alerted me to the redirect never clearing. Since I couldn’t login to my own app I restarted the server and everything was fine again.

I tend to use a log file on my web apps to track certain conditions and this morning I added more information so I could track this more. I just happened to be monitoring the app (in my browser) when my session count spiked to around 50 in just a few seconds. Looking at the new information in the log file the IP addresses were all over the place.  An attack?  I dunno but it sure seemed like it.

Unfortunately, the session count didn’t go down immediately like I expected it too and, in fact, it didn’t go down even up to an hour later. I had over a hundred open sessions before it stopped (did Xojo Cloud security close the port?).

When that happened I started looking at code. Some of this code I hadn’t looked at in a year or more. Basically the code did the two checks in the WebSession.Open even and if the function returned true I immediately tried to call WebSession.Quit.

Guess what happens when you do that? If you guessed nothing you’d be wrong. It generates a Nil Object Exception first with the following stack trace:

Function WebSession._WaitingForSync() as boolean
Sub

WebPushHandler.CheckForChanges()

Sub _SessionShutdownThread.Event_Run()

And after that then it does nothing. The WebSession never quits – ever – until something kills the app.

My solution was to put a timer property into the Session and if I meets my quit conditions start the timer and in the action event (using AddHandler) quit the Session. Seems to work as expected now.

This is filed in Feedback <feedback://showreport?report_id=35794> and it appears that it’s been verified. There are some additional details on their response. They know why it’s happening at least. Let’s hope this one gets fixed sooner rather than later.

I’ve seen various people have issues with WebSession.Quit over the years. This might be the root cause of some of those.

Thoughts on Xojo Web Edition

When Web Edition for Xojo (then Real Studio) was released I can’t say I was overly impressed.  It was missing some features and was buggy (to put it mildly).  I was of the opinion that it just wouldn’t take off.

Since then the worst of the bugs were fixed and the worst of the framework problems were addressed and there’s been a steady improvement in the product in practically every release.  In my consulting business it’s went from being a ‘gee that’s a nice thing to have’ to being roughly half of our overall Xojo consulting business.

The fact that we had very little web development experience hasn’t stopped us from using Xojo for a lot of projects.  It’s great that a WebButton and a regular desktop Button and that a WebPage and Window act the same from a developer standpoint.  All the code experience that we learned over the course of a decade in desktop apps was, with a few notable exceptions (*cough* constructors *cough*), was immediately transferrable to web apps.  While there is a learning curve it’s not like we had to learn a completely new programming language to do some large and complex web apps.  In fact, we turned down work before Web Edition came out simply because we didn’t have the experience and in-house know how to do the work.

Our clients seem willing to forgo the numerous capabilities and power of a desktop app for the more limited capabilities of a browser based app.  I think the biggest reason being that web apps don’t have distribution issues.  There’s only one instance of the app sitting on a server somewhere.  Web apps also work in almost every desktop browser and even work with most mobile web browsers.  Heck, you can even configure the web app to look different based upon what device it’s being viewed on.

There are some disadvantages, of course, to Xojo web apps.  You can’t just put them up on any ol’ server.  You pretty much need a VPS or use the new Xojo Cloud (which is just a specially configured VPS).  Then you have to worry about 32-bit compatibility libraries but, honestly, once you get the first app running on a server the rest of them are pretty easy.  I’ve not had the pleasure of getting a Xojo web app working on IIS but I hear it’s not a pleasure, nor quick, experience.

Apps running in a web browser have a limited subset of capabilities. With Xojo web apps you can’t use drag and drop anywhere out of the box (I think you can do some of this with JQuery but I’ve not tried yet).  The controls, particularly the WebListBox, are lacking a lot of functionality, and there’s just not a wealth of 3rd party controls available for Web Edition yet.

Security-wise, Xojo web apps are compiled making it very hard to compromise an app even if a hacker gets into your server.  There’s still work to make your app secure from SQL injection attacks but that’s a relatively simple thing.  Much of the work is really securing your server so that it’s secure and that’s one thing that Xojo Cloud is doing well (perhaps too well based on my recent experience).

So the question, Dear Readers, is what are your biggest likes and dislikes about Xojo Web Edition?  What do you wish it did better or differently?

JavaScript Error (or Banging Your Head Up Against a Wall)

In one of our big Web Edition projects I recently added a new dynamic WebContainer option to the home screen.  It generated a JavaScript error on occasion but because it was under active development I wasn’t too worried about it.  Sometimes those errors fix themselves given some time.

I figured that I was doing something to a control before it was being shown.  I went round and round with the bug adding timers to add delays and changing the order of when things were shown.  It was really bugging me and I even contacted Xojo support because it was happening on the Xojo Cloud server during the alpha period but yet I was seeing different behavior on my VPS host.

Eventually, we really looked at the javascript error:

document.getElementById(‘EK7iZlsZ’).style.overflow = ‘hidden’;

If you go into the Web Inspector in Safari and in the console paste in document.getElementById(‘EK7iZlsZ’) it resolves to a Style.  It was confusing because that style is used everywhere and all styles are static meaning that I’m not replacing or changing that style on any control, anywhere in the project.  We all assumed it was an order issue with the web framework.

The bit that finally tipped us off to what the real problem was the ‘style.overflow’ part of the JavaScript error.  That is NOT visibility of a control, that’s the JavaScript for ScrollbarsVisible and it’s a property on all WebContainers.  This is the property that will let you change how scrollbars work on the WebContainer.

Of course, once we knew what the error was it was trivial to change it.  The line of code I had in an initialization routine of the WebContainer was self.ScrollbarsVisible = 2.  As soon as I moved this to the shown event the problem went away.

If you are a heavy user of WebContainers this might bite you at some point in the future.  Perhaps you’ll remember this blog post and remember how you thought Bob was a silly old programmer for missing something so obvious.  🙂

Gotta love hours and hours of work for moving one line of code.  Of course, along the way things got more efficient and I removed a bunch of time delay code that was no longer needed.  I love programming some days.  Now to repair the dent in wall from banging my head….

Network Link Conditioner

If you’ve been using Xojo Web Edition for any length of time you’ve probably run into this problem:  You code your app and debug it on your local machine and you’re very happy with it but when you put it on your web server it’s slow, unresponsive, or generates some random javascript errors.

Welcome to web app programming.  What’s happening is that on your local machine there is, for all practical purposes, zero latency between the browser and the application.  You can do amazing things wish no latency issues.  I once had a working D&D Mapping helper for Dungeon Masters that used drag and drop on a web page.  That is until I put it on the web server and then it practically ground to a halt.  The end result is that it was a very hard lesson to learn (thankfully it was a ‘for fun’ project).  Drag and Drop in a Web Edition application really doesn’t work due to this latency (not even sure why the events are even there).

Latency is an issue all web apps have to deal with and since Xojo apps do nearly all of their processing on the server this can be of particular concern.  Short of putting the apps on my web server there wasn’t a lot I could do to test this until I found out about The Network Link Conditioner for Mac OS X.

Screen Shot 2013-12-14 at 5.32.53 PMThe Network Link Conditioner is available through Xcode and allows you to simulate network conditions on your Mac as if you didn’t have the super speedy connection you really have.  It’s quite instructional to do this.  You can simulate speeds from Edge, DSL, 3G, Wifi, and Cable Modem with varying degrees of lossy conditions in the wireless options.

To get The Network Link Condition open up Xcode and select the Xcode -> Open Developer Tool -> More Developer Tools and log into your Apple Developer Account and in the Downloads area search for Hardware IO Tools for Xcode.  This package includes a number of things, including the Network Link Conditioner preferences pane.  Download the disk image and mount it.  Simply double click on the Network Link Conditioner prefPane file and the Finder will install it in your System Preferences panel.

Then it’s simply a matter of starting it and selecting the network type you want to test against.  This tool is very cool and I highly recommend it if you are developing for Xojo web applications.  What it will show you is how slow your app is over these types of network connections and will most likely show you where you need to do some optimizations.  Perhaps you need to preload some things on your first page so they’re slower later on.

In one of our current projects we were loading a number of WebContainers dynamically.  This made sense since we felt we didn’t want to load everything when the user logged in and only load the container when they selected it.  This was great but this made the initial selection of the user slow as the server had to create the objects and then push them down to the browser.  The perception was that the app was very slow.

Of course, during development on our local machine we never saw that issue.  Everything was fast and speedy.  But when we started using the Network Link Conditioner we could see it rather well.  We also were able to replicate a few sporadic javascript errors that only occurred on the server (doing things in the WebContainer open events is bad too).

The solution was to load the pre-load containers when the user first logs in.  It takes longer at first, but when the user makes a selection the app has to only issue visible commands to the browser which is very fast.

A word of warning is in order.  Remember to turn Network Link Conditioner off!  It’s easy to forget that it’s on.  If you forget, though, your entire machine will seem slow if you’re doing anything over the network or internet!

What other tools and tips have you found for helping you debug your web applications?

RB Code Reports Updated

appicon64We updated RB Code Reports today after we realized that it wasn’t reporting properly against Web Edition projects.  The Statistics Report now shows Container Control, Web Container, and Web Page counts.  It did not before.

We also added a preference for the Signature Report so that you can now specify the scope of the signatures you want in the report.  For example if you wanted only Public, Protected, or Private methods/properties you can now filter on them.

It’s interesting.  Our big Web Edition project is now getting rather large.  228 Web Pages, 173 Web Containers and a little under 65,000 lines of actual code.  I estimate that we are less than 50% done.  We are definitely pushing the edge on Web Edition.  Fun, eh?

RB Code Reports Version 3.0.5 is a free update for all registered version 3 users.

For information at https://www.bkeeney.com/rb-code-reports/

Xojo Cloud

During last weeks XDC keynote Xojo Inc shared the status of the one-click web hosting that they talked about during last years Real World conference.  It will be released June 4 in Xojo 2013 Release 1.  It is now called Xojo Cloud.

One of the things that people have discovered while using Web Edition is that some shared hosting sites will tolerate web apps.  For a while.  And then terminate them when they use too many resources.  For example, I’ve been able to use a lightly trafficked Web Edition app on BlueHost with no issues but I certainly wouldn’t want to do that for our training app that runs all day long.

So this forces people into using a dedicated server or perhaps a Virtual Private Server (VPS).  Either solution requires some knowledge of Apache (assuming you’re using Apache), permissions, backups, and security settings to keep the bad guys out.

Xojo Cloud offers a zero configuration, one-click app installation with industrial strength security, along with automatic backups.  Perhaps the strength of Xojo Cloud is its predictable pricing model that starts at $49/month.  Different servers and different configurations may be more.

Each Xojo Cloud user gets their own Virtual Private Server running Security-Enhanced Linux.  It’s also running a custom-built Firewall that manages Smart Ports that let the IDE talk to the server by negotiating the opening and closing of ports when needed.  Another feature is Intrusion Detection that notified all the other servers in the Xojo Cloud that a breach has happened and minimized the damage.  Along with the Intrusion Detection Xojo Cloud offers Compromised File Detection so you’ll know what files have changed.  If an attacker does get through all those security features they still have to deal with a binary files.

Xojo Cloud is running on Rackspace starting in the data center in Chicago but eventually it will run in the Dallas, Virgian, London, Syndey, and Hong Kong data centers.  This lets you run your apps where your customers are.

One-click hosting in Xojo Cloud offers to take one of the pain points out deploying your web apps.  What we don’t know yet is how it will work with debugging and being able to test multiple versions of your web app.  Also one unknown is the availability of database servers.  It looks like that will NOT be a standard part of the configuration which is a real drag and in talking with other conference attendees this made ti a non-starter for them.

Only time will tell how well Xojo Cloud works for the average user.

Real Studio Schedule Change (Again)

Real Software announced today that the much vaunted and talked about new IDE is delayed yet again.  Real Studio 2012 Release 2 was released to the beta list today using the old IDE.  An alpha for 2013 Release 1 will be released (to alpha testers only) soon for us to evaluate and provide feedback on usability.

I have mixed feelings about the announcement.  First off, I’m glad they’re continuing updates using the venerable IDE user interface.  I know there are a number of bug fixes and enhancements that I can use on projects – right now.  The updates are welcome and hopefully no new bugs are introduced (though RS has done a couple of dot releases for Release 1 so I see no reason why it won’t continue as needed).

This announcement, in general, is a good thing and I’m glad that Real Software has decided that burning their bridges with the existing IDE just doesn’t serve us, the Real Studio developer community, very well.  The flip side, of course, is that every release they use the old IDE just pushes off the new one that much further into the future.

Like many Real Studio developers I’m still not convinced we are best served with a radically different IDE.  I believe minor tweaks to the existing IDE might be a better solution.  However, it might be a matter of scale that once you change one thing you have to change this, that, and everything else and by the time you’re done you’ve rewritten the whole user interface.  Add in the new iOS framework and editors and the changes to Web Edition and it might have been the only way to do it.  So perhaps this is a good change but only time, and usage, will tell.

I can’t wait to get my hands on the new IDE and work on my large projects.  I am curious to see how the always visible project tab will work.  If it makes life easier it will be a good thing.  If it hinders me in those areas I find important it will be a bad thing.  Obviously my opinion is the only that counts – to me, at least.  🙂

This announcement also pushes back the new licensing scheme and the one-click Web Edition deployment.  For some this is a big issue and for others not so much.  I guess that’s up to you to be mad, angry, or indifferent.

What do you think of this news?  Good, bad, or typical Real Software time slip?

FAQ: What Do I Do My Videos In?

One of the questions that I field, a lot, is what program to do I use to create my Real Studio Training (and other) videos?  The answer is ScreenFlow from Telestream.

When I first started thinking about training videos a little over 2 years ago I looked around and did my research.  ScreenFlow had most of what I wanted but the only thing it lacked (at the time) was an export to Flash.  I think within a matter of 3 or 4 months it was added in a new version.  I guess that’s one of the things I like about the software as they are always improving the product.

I think ScreenFlow is incredibly intuitive.  A simple interface starts and stop screen recording.  If you’ve ever used iMovie or Final Cut Pro to edit video the timeline editor is simple to figure out and intuit.  There are many options for zooming, and adding text and callouts, audio levels, cursor options, etc.  In other words, way too many features for me to spell out and frankly I use but a handful of them.

One of the bigger features that I use is the ability to Split a Clip and get rid of wasted time (like all the time I spend trying to figure out what I did wrong in my code, or redoing a sequence), or speeding up a long typing sequence.  Also, being able to mute the inevitable cough or the cell phone ringing is pretty important.

ScreenFlow has a number of exporting options but since it didn’t export to Flash (at the time) I ended up using iMedia Converter from iSkySoft.  It converts practically every audio and video format you can think of.  I used this to figure out the byzantine ways of getting Joomla to display both HTML5 video and Flash.  I could use ScreenFlows export now, but since I can do batch processing in iMedia Converter I can literally let it run overnight and do 40 or 50 videos if I need to.

One of the things I learned when doing the ARBP conferences was that good audio is critical.  Use a Plantronics gaming headset that plugs in via USB.  My only complain wasn’t with Plantronics, but with Apple.  If I recorded a video where I did recording for over 45 minutes, I would consistently have three minutes of static filled audio.  Then it would go away but it makes for bad audio at that point.  Sometimes it doesn’t affect anything and sometimes it does.  I haven’t done a really long video in a while so this problem might not be there now.

I talked earlier about Joomla and how I found it difficult to get video up and running.  Now our training is 100% Real Studio Web Edition.  Not that Web Edition is perfect, but I’ve been able to add more features to it in 4 months than I was able to do with Joomla with 2 years of trials and tribulations.  At least with Web Edition I have more control over the web app than I did with Joomla.

In fact we’ll be integrating closed captions to the training videos, first in English, and then hopefully in French and Spanish.  This is enough info for another post describing what a pain that’s been, but let’s just say that it’s coming “soon”-ish.  Currently I’m handling all of the PayPal transactions manually so there’s some delay between payment and me actually setting it up and we’re hoping in the next couple of weeks to get PayPal fully integrated so I don’t have to do any manual setup anymore.  Did I mention how much I like having more control over the app?

Anyway, this has turned into a longer post than I anticipated.  Thanks for your support!

Bugs Are In The Eye of the Beholder

The other day someone on the NUG list posted a somewhat lengthy message on Web Edition bugs. They were asking “why was Web Edition so buggy after a whole year?” Here is my response (mostly the same but with some changes).

Sure, Web Edition has more than its share of bugs. Like all bugs, however, it all depends upon the beholder.  What bug causes the most pain for RS’ is the one that gets fixed first.  I’ve seen a lot of the same things the community has discovered and have just worked around them (where I can).  I was using WE in a commercial project during the first beta ( a year ago) and while we got it to work it wasn’t very good.  That one project probably generated over a hundred feedback reports.  In my opinion WE really hasn’t really been usable until 2011 R3.

Part of the problem, in my opinion, is that RS has NOT created enough Web Edition applications for themselves.  If you don’t thoroughly exercise the framework you just don’t see the things you’d see in a big, complex application (like we are creating).  There is ONE real world example of Web Edition on their website.  While I don’t know how many examples are ‘enough’, I know that one is definitely not enough.

Web Edition exposes the same problems that we all see in Cocoa, Carbon, and in the IDE on a regular basis.  Unless RS experiences the pain it won’t get fixed in a timely manner because it’s not as important to them.  The Reporting editor and generator and the database editor are but two examples of things in the IDE that RS doesn’t use in ANY of their products. It shows because there are gaping wholes in usage that make them unusable for many developers.

RS takes pride in saying they eat their own dog food because they use Real Studio to make Real Studio.  Admirable, but they tend to be on a restricted diet since they don’t eat everything on the menu.  They rarely change the menu’s for the IDE so the Menu Editor hasn’t seen many changes or enhancements.  As far as I know, they don’t use a database in the IDE so I see no reason why they’d be using the database editor on a regular basis.  They don’t do much with StyledText or Movies so its no surprise that those classes are minimalistic (at best).

Since the IDE has no need for date pickers, they have never provided one.  Likewise, the Listbox is good enough for the IDE while we’ve been asking for a more powerful grid component for years.  Full RTF support?  Forget about it because StyledText is good enough for the IDE. A better toolbar control? Well that one’s a bit of a mystery since the IDE is obviously using something different than what they provide to us.

My point is I’m not sure why anyone would be perplexed about long standing bugs.  Sure, they’re painful to you and me (and my clients), but they’re not (as) painful to RS.

Lobbying the community to get Feedback reports higher in the list is about the only way to realistically get a bug fixed. But even that is a crap shoot as there are quite a few bugs (not feature requests) very high on the list that have been there for a long time. So the only thing conclusion that I can come up with is that the bug that all the rest of us are seeing isn’t painful to RS so therefor it isn’t a priority for them.

This is my opinion as a ten year Real Studio consultant.  I know and respect most of the engineers and staff at RS and I think they do a remarkable job.  However, I think as a company they mostly ignore those like me (an Enterprise user that ponies up thousands of dollars per year) and focus, almost exclusively, on the hobbyists (that bring in a hundred dollars a year at best).  If they could make me happy(ier) the hobbyists would come along anyway (see history of Visual Basic).

Bugs happen in every software product. I remember grousing about Visual Basic bugs when I was a big VB6 user. I know that my code back then had plenty of work arounds for bugs in their API. There is no doubt that Microsoft had more developers working on the product (as a whole) than RS has working on Real Studio. There’s also no doubt that VB6 has a considerably larger user base than Real Studio. I feel that this resulted in more workarounds being posted and more alternate solutions.  The reverse is that our smaller community doesn’t have as many solutions and documented workarounds so it feels worse but I feel that it isn’t.

Anyway, that’s enough on my opinions about bugs and such.  Have a good New Year and be safe. Happy coding!