REAL Studio 2010 R2 Review

I posted my REAL Studio 2010 R2 review on the Association of REALbasic Professionals website.  All-in-All, a decent release (with a few issues) that should please most Windows developers.  Still no Cocoa, though.

What I didn’t say in the review (and will probably be in another post) is that the beta process does not appear to be working very well.  A number of minor (to everyone but the feedback reporter I’m sure) issues were marked as fixed and were clearly not.  I can’t complain too much because I didn’t get a chance to do ANY testing for R2 (because I’m crazy busy with RB work).  Ironic, no?

9 thoughts on “REAL Studio 2010 R2 Review

  1. Usually I agree with the majority of your reviews Bob, and I always find them extremely informative. But I can’t agree with your statement of it being impossible to write flicker-free Win32 applications. It certainly is possible (even when mixing native and custom controls), and I’ve found RS’ stance on that topic to be an offense to user’s intelligence.

    I’m also sad to see that RS is actually *encouraging* users to share dynamic libraries between application instances. Either install the application using a real installer, or keep your DLLs segregated. That hybrid solution is a proven “Terrible Idea”, and has been for a decade.

  2. Nice review Bob. There are a couple of things your review didn’t mention. The Listbox headers don’t flicker as much anymore and the TabPanel (almost certainly the worst offender of them all) is dramatically improved as well.

    We had hoped to make all the database plug-ins non-blocking in this release. REALSQLDatabase has been updated but did not make it into this release. ODBCDatabase has also not been updated but should be for R3.

  3. Thanks, Geoff. I forgot about the TabPanel. I didn’t mention the listbox headers because in my testing they are non-functional in Windows. No text is shown at all. Certainly no flicker, but no text either. I had initially thought this was a bug specific to R2 to when reverting to R1 to test I had the same issue. Other than that I’ve not had a chance to test further or submit a feedback report.

    Thanks for the update on the database plugins. The release notes specifically mentioned MySQL and PostgreSQL and maybe I remembered the REALSQLDatabase from a beta note somewhere. Regardless, I know the PostgreSQL plugin has some issues.

    I will update the article accordingly when I get a chance.

  4. There is a known issue with listbox headers not appearing on Windows. The workaround is to set the Listbox’s textunit property equal to itself in the open event:

    me.TextUnit=me.TextUnit

    This is already fixed in r3. It’s not a bug that was created by the flicker improvement. It’s from back when we added the TextUnit property. And this bug doesn’t occur for everyone. It’s a bit random.

  5. @Aaron Ballman
    Bob hit the nail on the head with his comment about “These changes are welcome for those developers that have a suite of applications that use the same DLL’s as it will reduce deployment size.”
    Even with disks being relatively cheap a suite of co-operating REAL Studio applications could chew up a lot of disk space without the ability to use one common set of DLL’s.
    This commonly affects people who do ship multiple applications as part of their solution and was frequently cited as an impediment.

  6. the new Libs folder is clearly the best. But I suggest RS adds the version number to the dll names as the MBS Plugins. See http://www.mbsplugins.de/images/obfuscatedbeforewin.jpg screenshot. The plugins use the build number there to make files unique.
    Why? Because over several years you switch versions and if your users mix versions of your apps and mix the libs together, you get in trouble. If one RB app requires shell dll from RB 2010 and another the dll from RB 2011. If the interfaces do not match, the plugin loader will complain.

  7. The reason this was added was because the people who wanted it said “we’ll keep track of the versions and make sure our suite of software uses the right versions”. They knew full well that asking for and getting this request implemented would be their own version of DLL they’d have to manage.

    IF you don’t want that task then DON’T use the feature and you can be sure that the right app uses the right DLL’s and version conflicts won’t be an issue.

Comments are closed.