Don’t Convert Your App to Xojo

New Xojo developers are often sorely disappointed with Xojo when first coming to the language.  Why?  The complaints are varied but they usually say things like “<insert part here> doesn’t work right.  In <insert old dev environment> it worked this way.”  I’ve heard this complaint so often that I ignore it.  Don’t convert your app to Xojo, rewrite it in Xojo.

Xojo attracts a lot of VB6 developers.  The IDE’s look a lot alike and the languages at first glance are pretty similar.  The problem is that Xojo isn’t VB6 and most of the things that take huge workarounds in VB6 are almost laughably simple in Xojo.

The first thing many people do is look at the VB Migration Assistant from Xojo.  It isn’t a perfect tool and does not convert any code for you.  Not converting code is actually a good thing because no conversion tool is perfect.  It’s very hard to convert the intent of the original programmer.  Sure, there are rules you could employ to convert code but in my experience the converters create more work for you in the long run.  It’s much easier for a human to look at the VB6 code, figure out the Xojo equivalent and use the Xojo-way of doing things.

At best, the VB Migration Assistant will convert your UI for you.  But given the huge diversity of 3rd party controls for VB6 you will have to work at converting them to standard Xojo controls.  And again, because VB6 doesn’t do some things well, like control subclassing, you might actually be better off rewriting the user interface from scratch in Xojo anyway.

In both cases I said rewriting Xojo.  Sorry.  There is no easy solution to get your VB6 application to work in Xojo.  While the two development tools use a BASIC language that’s about as close as they get.  VB6 is an ancient language by modern standards.  Xojo is updated 4 to 5 times a year and VB6 hasn’t been updated in a long, long time.  Control subclassing in VB6 is impossible and threads are very hard and because of these two things most VB6 apps tend to have huge workarounds to fulfill those needs.

In Xojo these issues just aren’t there.  Subclass controls to your hearts content.  Need a thread or two or a dozen?  No problem it’s a simple to use Xojo class.  Need a 64 bit version?  Want it to run on Mac OS X, Windows, Linux, and Raspberry Pi?  Xojo can do all that easily.  For VB6 that impossible.

If you are contemplating switching to Xojo do NOT look at ‘converting’ your application.  Think about rewriting it.  This means doing some legwork upfront to learn the Xojo particulars and only then writing code.

We’ve converted dozens of VB6 apps over the past fifteen years as Xojo consultants.  We’ve helped teach thousands of developers on how to use Xojo with our Xojo training videos and one-on-one training.  In the long run you’ll be much better off learning the Xojo way of doing things.  Perhaps then you’ll appreciate that Xojo did it better.

Shorts Report Designer 1.5.3

We released version 1.5.3 of BKS Shorts today.  A number of bug fixes, changes, and additions were added.  The change list below.

I will be the showing off Shorts at the next Xojo webinar on February 2nd at at 1:00 PM (GMT-5:00) Eastern Time (US and Canada).   Signup at https://zoom.us/webinar/register/7a19681a9a0c3f5f7c24e00bf0acd2b8

One of the new items is the ability to show a Row Number on any band using the new SC_GetCount XojoScript.  Add this to any Band Script to modify a TextItem.

We added a couple of new examples based on user feedback.  The first is using the SC_GetCount Band Script to set row numbers.  The second, is an example of how to print directly to a printer without having to go through the viewer.

Change List:

  • Added SC_GetCount in the Band XojoScript editor. This lets you get how many times this band has been shown.  Example of use is to have line numbers on your report without having to do it in SQL.
  • Updated German localization
  • Rearranged UI on ccPAF_Filter (Filter Data) to make it a bit more obvious
  • As a Text Item or Field Item are put on a report it will automatically use the “Default Style”
  • Fixed an issue where the Default Style wasn’t getting passed to the generated report.
  • The Styles Editor now allows you to delete multiple Styles at a time.
  • Added a new example of how to print directly to printer without having to use the viewer.
  • Reconfigured Demo window to break between Report Designer stuff and older code-only stuff.
  • Added SC_GetCount Demo
  • Fixed some items in the HTML Renderer
  • In PAF_PrintKit.PrintText.constructor if there is no DefaultStyle we create one.
  • ReportPF will now extract Styles from the report definition file.

BKS Shorts with the Report Designer is $300 and you get the full source code.  More information can be found at http://www.bkeeney.com/allproducts/bkeeney-shorts/

 

Implicit Instance is Evil

Xojo has had Implicit Instances of Windows and WebPages from the very beginning and I was so happy when they gave us the option of using it or not.  I can tell you from experience debugging newbie apps that Implicit Instance is evil because it often leads to subtle and hard to find errors.

The implicit instance lets us do some very simple things like:

window1.show

Window1 is shown.  No big deal.  For simple apps this is no problem and fast and easy.  That simplicity comes with some perils because window1 loads whenever any control or property on that window is checked.

For example, a lot of developers will do something  like this:

window1.close //close the window

if window1 <> nil then
   
   //Window is open.  WTF!  I just closed it!
   
end

The problem is that simply by doing this comparison, window1 is loaded into memory and depending on the other window settings it may become visible.  It drives developer crazy.

Setting ImplicitInstance = false forces the developer to make a new instance of Window1 if they want to use it:

dim w as new Window1

w.show

I think this is the preferable approach because it’s safer.  It will never give you Window1 by accident.  In fact, if you attempt to do this with window1.implicitinstace = false:

if window1 <> nil then
   
   //Do something.
   
end

The Xojo compiler will give you an error that says:  Expected a value of type class Window1.Window1, but found a static namespace reference to class Window1.Window1.  This is a roundabout way of saying you can’t call window1 directly since that’s the class name when in reality you need to be checking for an instance of the class. That class instance cannot be named Window1 (because that’s the class name).

So how would you check to see if a Window is already open?  That’s easy.  The Window and WindowCount methods are there for you to do just that.  Iterate through the window listing and when you use the ISA method to ask if it’s of type Window1.  If it is, then do something.

  for i as integer = 0 to WindowCount-1

if window(i) isa Window1 then
   
   //Do something with the Window1 instance.
   
   //You have to cast it as Window1 from the Window method
   
   dim w as window1
   
   w = Window1(window(i))
   
   w.someproperty = false //set a public property
   
   w.LoadNewData //call a public method
   
   w.show //brings the window to the front
   
end

next

A common thing to do is close all instances of a particular window.  Using the above code might fail if you have multiple instances of a window open.  Here is the code that closes all instances of a type of window.

  for i as integer = windowcount-1 downto 0

if window(i) isa Window1 then
   
   window(i).close
      
   end
   
next

In this case we must iterate backwards through the array.  Think about it if you are confused as to why.  Better yet, test it yourself.

Web apps have a similar property in the WebSession.PageCount and WebSession.PageAtIndex methods.

  for i as integer = 0 to session.PageCount-1

dim w as WebPage = Session.PageAtIndex(i)

if w is a WebPage1 then
   
   //do something with WebPage1
   
end

next

The drawback, if you can call it that, to having Implicit Instance = false is that as you call new windows or web pages you haven’t done anything to the old ones.  Depending upon your application this may cause long term memory issues especially as the app gets a collection of pages that are no longer used.   For short lived apps this usually isn’t a problem.

To solve this you can either iterate through the existing windows/pages to find the one you’re looking to reuse or simply close it as you open your new one.  Either way, I don’t think the burden is too high.

It is my not-so-humble opinion, that leaving ImplicitInstance = true is bad for you as a Xojo programmer.  Simply put, Implicit Instance is evil and you should avoid using it – especially in larger applications.

What say you my Xojo developers?    Do you like to turn Implicit Instance off or do you even care?

BKS Shorts Report Designer

picAppIcon256BKeeney Software is pleased to announce version 1.5 of BKeeney Shorts, our reporting classes for Xojo.  This free update for Short Professional users is a major update to the tool and includes a set of classes that allow developers to embed a report designer into their Xojo applications.

Since its release in 2013 BKeeney Shorts has been used by Xojo programmers around the world to create complex reports using nothing but Xojo code.  The number one request from users was to have an external reporting tool that let them create reports quickly and easily without the need to code the entire report.  With the Report Designer we’ve removed the need to code all but the most complex of reports:  most reports can be created in minutes instead of hours.

Gems Report Designer

Included in the BKS Shorts demo project is a fully functioning Report Designer.  Developers can copy and paste the Xojo code into their own project and integrate the Designer in just a few minutes.

Reports are saved in a simple JSON string that allows the developer to have reports defined outside of their project.  The Demo project saves a report file but a Xojo programmer can easily save them as strings for use in their own document or database.

Reports Bands can run XojoScript code to do complex runtime actions such as change text, styles, concatenate text, show images and much more.  This allows end-user changes in a report without the developer coding it up front and having to recompile the executable.

Gems Report Rendered

BKeeney Shorts Professional costs $300 and comes with full, 100% unencrypted source code.  To export to PDF (without a watermark) a separate purchase of the MonkeyBread DynaPDF Starter plugin is required.  This is a free update to existing Shorts Professional users and a $75 update to existing Shorts Standard Users.

BKeeney Shorts requires Xojo 2014 R3 or better.

Homepage:  http://www.bkeeney.com/allproducts/bkeeney-shorts/

Video of Report Designer in Action:  http://www.bkeeney.com/allproducts/bkeeney-shorts/shorts-designer-in-action/

Video of Integrating the Report Designer:  http://www.bkeeney.com/allproducts/bkeeney-shorts/integrating-shorts-report-designer/

For questions regarding BKS Shorts, please contact Bob Keeney at support@bkeeney.com

Xojo Code Folding

I was talking with another Xojo developer and we both commented on how neither of us use Code Folding in the Code Editor.  I’ve been using Xojo for fifteen years and this developer is at least ten years.

For-Next

For-Next regular

If you’re not familiar with code folding it’s the ability to collapse an entire branch of an If – Then statement, Select – Case, For – Next, While – Wend, and probably a few others.  The code doesn’t go away, it’s just temporarily hidden.  It’s a convenient way to hide a good chunk of code so you can easily see what else is going on around it.

For Next Collapsed

For Next Collapsed

The other developer and I discussed this issue for a while and we really couldn’t come up with a good reason why.  The best reason we could come up with is that it *looks* like the code has been deleted.  Like I said, it wasn’t a good reason but at least it was a reason.

Do you use Code Folding? If not, why?

Have a Merry Christmas and Happy New Year folks!  Stay safe, enjoy time your family, and happy coding!

Presentation Tips

Giving a presentation for a room full of people can be a nerve-racking experience.  I remember the first time I gave one at the Xojo Developer Conference and I honestly can’t recall how I did.  They let me speak again so I must not have been too bad.

Years later I started doing Xojo training videos and had to edit myself speaking.  It was an awful experience to listen to myself fumble through words, use necessary filler words, and clean it all up.  It was after a couple of months of doing this that I decided to get some professional training.

After some training and many more presentations and videos I feel I’m much better (but still not perfect).  Here are some simple rules for making your presentation experience better.

Practice your presentation.  This seems like such a simple thing but I’ve seen way too many presentations where the presenter get up in front of the room and you can seem them searching for words to fill the time.  Most people, when they’re winging it, use their predominate filler words.

This should rarely happen and the easiest way to avoid this is to practice, out loud, your presentation.  Even better, practice it in front of someone else or record yourself.  Then get your listeners feedback or listen to it yourself and find out where you sounded awkward or stumbled.  Those are areas to go through again so they’re smooth by the time you do it live.

Don’t Read Your Slides.  Not only is reading your slides annoying to the audience but also makes it appears like you’ve not practiced.  Whatever you’ve written on the slide should be summarized verbally.  This way the user sees a slight variation from what you said and has to think about it a bit more.  And perhaps more importantly, they’re not annoyed that you’re reading to them.

Another way to do this is use short bullet-point text and what you say is the expanded version.  The bullet-point text on the screen is the summary and what you say is the expanded version.  Either way don’t read it!

Use the Equipment Before the Presentation.  Most computers and projectors work smoothly these days but it doesn’t hurt to connect up beforehand and go through some slides just to make sure it works properly.  This way your presentation starts properly and you don’t have to apologize and take time out to fix things.

As a software developer talking to other developers it’s common for me to give a demo that’s not in Keynote or PowerPoint so I’m switching from the presentation mode to the computer view.  When doing this make sure you have someone in the back of the room give you feedback on sizing of text and pictures..

I can’t emphasize this last point enough.  With todays high resolution monitors what looks huge on our big, Retina display may look tiny on the projector you’re using and impossible to read in the back of the room.  You might have to adjust the resolution on your computer to make it larger.  Make sure any application you’re using at this lower resolution works properly too and settings adjusted beforehand.

Another good habit to get into is look at the colors your using.  On your monitor they might look really nice but on a projector in a well lit room they may look washed out and impossible to read.  Using a dark purple on a black screen might be a bad choice as well as using green on a white background.

Any text you have on your slides should be as large as possible.  Despite looking awful on your monitor the people in the back of the room will appreciate being able to read it.

Never Go Off Script.  If you’ve practiced your presentation you should have it down pat.  Do not decide during the presentation to add additional information or demo something you didn’t practice.  From my own experience this where things go off the rails.  In the heat of the moment words can fail, filler words come out, and it’s an overall awkward moment in an otherwise good presentation.  On the flip side, if you can think of additional material add at the last moment you probably didn’t practice enough.

If you have a Q & A section of your presentation you can bring it up then or wait for someone to ask about it.  This is meant to be an unscripted portion of your presentation so people will give you some slack.

Breathe.  This seems simple, but I’ve seen a lot of speakers get up and be in such a rush to get their presentation underway that they forget to breathe.  Proper breathing technique means giving the audience a chance to process your information before going on to the next topic.  Wait a second or two before advancing your slide.

What seems like an eternity of empty space for you is good for the audience.  Silence does not have to be filled by you.  Respect your audience and give them time.  Respect yourself too because that pause to breathe is also time for your brain to start formulating your next thought.

My own personal issue with this is in the Q & A session.  Because it’s off script and somewhat random it’s easy to rush into it.  Try to take a deep breath before starting the answer and take another one after you’ve finished.  Again, this is as much for the audience as it is for you!

Get Training.  All of these tips are incredibly hard unless you practice.  You can learn them on your own and I’ve met some very talented natural speakers that can do this.  Most people aren’t naturally talented enough and have to work at it.  I highly recommend joining an organization, like Toastmasters, that can help train you on public speaking.  They are an international organization and there are chapters everywhere.  Their entire purpose is to help you succeed with public speaking.

Giving a presentation doesn’t have to be a stressful experience for you or your audience.  Use these techniques to polish and put a shine on your presentations.

What presentation tips do you have that I missed?

Xojo 2015 R4

Xojo 2015 Release 4 hit the internet today.  The fourth release of Xojo this year is full of bug fixes and only has a few new items.  I’d recommend using this release as the bug fixes are substantial.

Let’s get what’s NOT in this release out of the way.  This release was initially supposed to be about getting Retina and HiDPI capabilities in the IDE and in our applications.  It was determined that there just wasn’t enough time before the end of the year to get it done.  It’s disappointing to not get these new capabilities but I’d rather they be done right than Xojo giving us a half-assed feature that no one is really happy with.

This release also does not complete the 64-bit work started in 2015 Release 3.  We still cannot use the Remote Debugger to live debug 64-bit applications and there are still major gaps in the capabilities between 32-bit and 64-bit applications.  A full list is here:  http://developer.xojo.com/64-bit-guidelines

Changes and Fixes

What this release does is fix over one hundred compiler, framework, database, and IDE bugs.  There a number of 64-bit bugs that have been squashed that were causing linking errors or outright crashes when compiling 64-bit applications.

For the framework there are a couple of high profile fixes that are welcome.  XML Exceptions no longer ‘skip’ exception handlers.  I know this has been troublesome for many developers.  An issue with the new Xojo.IO.Folderitem class has been fixed on Cocoa that would cause crashing when a FolderItem object was put in a tag, for example.

The Web framework received

some bug fixes as well.  Some of the more notable:  WebSessions no longer quit when moving from network to network.  WebPicture’s no longer return nil when defined from a FolderItem and the WebPicture no longer uses twice the memory when the image is in the project file.  The web framework now recognizes the Epiphany web browser on Raspberry Pi.

The WebDragItem now has the Origin X and Y values that indicate the X and Y coordinates of the Sender web control where the drag began.  I haven’t tried this out yet, but this should make some things (like a web based designer) a little easier to create.

The MSSQLServer Prepared Statement no longer returns a nil and should allow developers to use this safer method of using Xojo with Microsoft SQL Server database servers.  The ODBC Database plugin also got an update so it no longer crashes when retrieving large SQL columns.

The IDE has dozens of bug fixes.  Most of them pretty minor but they add up.  Among the more notable fixes:  AutoComplete has had extensive work so that control arrays and structures should work.   Private methods and properties now show in AutoComplete as expected (now, only when in scope).

The Syntax Help Area (at the bottom of the Code Editor) is now scrollable  when the content does not fit the preexisting area.    This area will also show the description, if there is one, in addition to the signature.

The Interface dialog now resizes itself to 75% of the window height.  If you make it larger it will reopen at that size (or the limits of the window).

Filtering in the Navigator now shows results ordered on how closely they match the string based on the Levenshtein distance of the match.  So if you don’t quite get the name right you might still get results instead of requiring an exact match.

New Stuff

Despite this being a mostly bug fix release there are a couple of new goodies that might make your day.  The first is that MySQLCommunityServer now has a SecureAuth property which allows users to authenticate using old password hashes.

The Graphics class for desktop apps has a new property, called CharacterSpacing, that allows you to change the percentage spacing between characters.  You can use both positive and negative values.

Web Text controls now have a TextAlign property.  This should simplify web projects as you no longer do have to duplicate a WebStyle and change the alignment simply to change the text alignment for a single control.  You can still do that but this is a new way to eliminate that extra work.

In some preparation for Retina, Image Sets are now available.  Use the Insert Menu and select Image.  In the Image Set editor that are now 3 thumbnails for the set for normal size, double size, and triple size.  But since this release doesn’t include Retina support this feature is of limited usefulness – for now.

What might be the biggest news of the release is the addition of the CGFloat data type.  This temporary datatype aliases to a Single in 32-bit builds and a Double in 64-bit builds.  This should make fixing some the common libraries (think MacOSLib) easier since we can make one variable that will work for both build types.  Xojo has said that once 64-bit iOS and OS X builds are ONLY 64-bit the CGFloat data type will be deprecated.

Future Releases

I’m a big fan of these mostly bug fix releases.  In a product that changes so much and so quickly (at times), these bug fixes releases allow us to take a deep breath and not worry too much about using this release.  We worry about the big releases because of the shear amount of changes involved and the amount of testing required with our applications.

So what do we have to look forward to in 2016?  Presumably, 2016 will see a full compliment of Retina and HiDPI support since Xojo publicly pulled it from this release.  I would also expect the 64-bit journey to continue with hopefully the IDE becoming 64-bit which means that XojoScript, Windows version and icon information work, and the grandaddy of them all, Remote Debugging work in 64-bit.

I hope we get a Remote Debugger for Raspberry Pi simply because that will make life easier on that platform too.  I’m not sure what else we really need for Raspberry Pi.  What have I forgotten?

I would expect the IDE to get some level of redesign.  Many people, including myself, are unhappy with the workflow in Xojo and think it’s slower to use than Real Studio.  I know of several large customers that have stuck with Real Studio rather than migrate their projects to Xojo simply because of the IDE workflow issues.  Personally I’m happy that Xojo plans to address some of those issues.

I expect the iOS framework to grow with new controls and capabilities.  I also expect the new Xojo framework to keep growing (TCP Socket perhaps being the biggest need) and getting more attention to eliminate some of the cross platform bugs in it (looking at you HTTPSocket).

Will 2016 be the year that the desktop or web frameworks gets rewritten for the Xojo framework?  Perhaps, but Xojo isn’t saying much.  With XDC now in October we won’t get much of a hint of future plans until then, or until we see it in a beta cycle.

I know that Android support is at the top of the wish list in Feedback.  I do NOT see it in 2016 simply because it’s yet another platform.  Unless they’ve already started the work on it (which is always possible and we haven’t noticed it) I expect it to take at least 18 months (more likely two years) for an Android beta release.  And even then, how long until it’s really usable?

So what is your take on this release?  Good, bad, or meh?  What are you most looking forward to in 2016 from Xojo?

Listbox and Tag Options

The Listbox is a very powerful control, in my opinion.  Out of the box it doesn’t have a lot of capabilities but it’s easily extendable and it’s possible to create some complex grid-like applications using the standard Listbox.  Is it perfect?  No, but it’s more than adequate for most developer needs.  There are a number of options for showing and storing data.

A new user to Xojo recently asked me about the various tag options in the Xojo Listbox.  She wasn’t sure when you’d want to use RowTag versus ColumnTag versus CellTag.  It was a good question – I hadn’t given it much thought.  I like questions like this because it forces me to think like a new Xojo developer.

Most Tags in Xojo are the Variant datatype and that means they are very good at storing whatever you want in them.  We often say, “just stash the data in the tag”.  Since you can put practically anything in a variant it’s very convenient to use it.  I suspect that whenever the new framework makes it into UI elements the tag will turn into an Auto variable (which will lead to interesting problems but that’s a post for another time).

When it comes to the Xojo Listbox, I know some Xojo developers like to make columns of zero width and put data in these hidden cells.  I dislike this approach for several reasons.  One, it limits what the listbox GUI can do.  A zero width column means that you probably don’t have column resizing on (and if you do the columns are accessible to the user).  Two, it’s not how the control was intended to be used.  Three, we have Tag options to eliminate the need to do this.

We predominantly use the Listbox.RowTag property to store our data.  A vast majority of our projects are database driven and since we use ActiveRecord a lot we almost always have a class object (the ActiveRecord object) that has our record stashed away in the RowTag property.  The listbox may only have 2 or 3 visible columns of data but the ActiveRecord object might have dozens of properties (which reflect the fields in the table).

This gives us the advantage that we only have to query the database once and that’s to load the listbox.  Subsequent edit/update and delete operations simply use the object that’s already in the RowTag.  The user selects the row, we get the object out of the RowTag property and then pass it on to whatever method needs to work with it.  This fits 95% of everything we ever do with a Listbox.

The CellTag comes in on projects where we’re not using ActiveRecord.  Things like preferences come to mind where it’s data but not database related.  We load the Listbox cell data with what the user can edit.  Then, in the CellTag property put a copy of the visible data so later on we can compare the Cell text to what’s in the CellTag.  Even in this case, though, we still use the RowTag property for identification purposes.

Using the CellTag and comparing it to the Cell text is convenient when doing inline-editing of the Listbox data.  The comparison can happen at the Cell Lost Focus event or in a generic Validate method before saving the data.  Either way, the CellTag data is ‘hidden’ and the user can’t mess with it.

The ColumnTag has been around a couple of years and I can’t say we’ve used it much.  I can see the benefit of using it, however, to make things like Pivot Table using the Listbox.  This isn’t a trivial task, mind you, but I would treat it like the RowTag.  It’s there for use and I’m sure someone out there has a reason to use it.

If you find yourself making zero width columns to store data in your Listbox you should look at the various Tag properties.  Trust me, it will make your application work better and be safer with your data.

What interesting things do you use Listbox tags for?

Should you Mix and Match Old and New Framework?

When Xojo introduced the iOS framework when Xojo 2015 R1 came out we got introduced to the new Xojo framework.  It was only required for iOS and were told that it would eventually get added to the other targets.  Xojo 2015 R2 introduced much of the new Xojo framework into the desktop framework.  Many people are curious if it’s time to start using the new framework.  Is it safe to use?

Let’s get this clear up front.  There is no reason why you have to use the new Xojo framework.  Sure, it’s the future but the old framework will work for many years to come and there are huge gaps in the Xojo framework that haven’t been addressed yet.

My first bit of advice is to not dive headfirst into mixing and matching the old and new frameworks just yet.  It can be an exercise is frustration.  Take, for example, this bit of code:



dim d as new xojo.Core.Dictionary

d.value(kMachineName) = MachineName.ToText

if d.value(kMachineName) = “” then
   
   break
   
end

Looks like it should work on desktop, right?  It doesn’t because when you get to the comparison it generates an exception.  When you break it down it makes sense because the Auto value you get from DictionaryValue is a Text type and you’re comparing it to a String type.  The two are not equivalent.

The way around this, that seems to work, is to do this:



dim tBlank as Text

if d.value(kMachineName) = tBlank then
   
   break //handle error
   
end

Obviously if I was using Text everywhere this wouldn’t be a problem.  But this is a desktop app and the major gaps in the Xojo framework start to show up.  The database classes will only accept Strings so you have to do some conversion.  This isn’t a big deal, but it’s one more thing to worry about and deal with when exceptions come up.

99% of our consulting applications are database driven so not having the database classes in the new framework are a major hindrance to us to adopting the Xojo framework.  Frankly, if it weren’t for the client wanting us to use the new framework whenever we can we’d not be using it yet.

Some of the parts of the Xojo framework that are done aren’t fully fleshed out.  For the past couple of weeks I’ve been working with the xojo.net.httpsocket class.  Works great on Mac OS X and Linux (surprisingly enough) but when I get into Windows for testing it just does nothing – no exceptions, no errors – it just absorbs commands.  The first reports of issues happening in Windows were reported in back in August but that report was closed as not reproducible.

When it comes to the networking classes the new TCPSocket class still hasn’t been ported to non-iOS targets yet.  Neither has any of the UDP and ITC classes and, in general, there are still a lot of old global framework classes that haven’t been ported yet.

This makes sense because iOS and then 64 bit took a lot of time and resources to get to the state they’re in today.  I would argue iOS isn’t complete yet but that’s an argument for another day.  It looks like 2015 R4 will be mostly Retina support so we are many months away from some of these gaps getting filled.

I am curious to hear other Xojo developers experience with using the new framework.  For me it’s been frustrating from the lack of examples in the documentation, to it just working differently than the old framework, to the new classes not working as they should, to not having a complete framework to pull from and the messiness from commingling the old and new frameworks.  My advice would be hold off on trying to use the new framework in a desktop, console, or web app until there’s more of it.

What’s your experience with the new framework?

Xojo Conference in London

With a little over a week to go there’s still space available at the MBS Conference in London the 27th of November.  It will be held at the Antoinette Hotel in Wimbledon which is a part of greater London.  The conference homepage is at http://www.mbs-plugins.de/archive/2015-11-11/Schedule_for_MBS_Xojo_Conferen/monkeybreadsoftware_blog_xojo.  There are still spots available!

This is during the Thanksgiving Holiday weekend for the United States but if you want to avoid your crazy relatives join us in London and get your geek on.  Airfare is reasonable this time of year to London.

Give it some thought and think about joining us.  I went to one of the conferences in Koblenz, Germany a few years ago and had a blast.  There is nothing like getting together with like minded people to chat about your favorite development tool.

I’m going to give a presentation on BKS Shorts and the new Report Designer that will soon ship.  I think people will be very happy with the ability to embed a report designer into their applications AND have the ability to modify the UI as they see fit.