Saturday, 20 February 2016

Keyboard Issues with OS X Lion And Above

This may well be old news to some people, but it is only a recent discovery for me.
I was working on a small application that needed a custom text input field, however, when I was testing it, I couldn't get certain keys to repeatedly call the MouseDown event, and yet others did.
I found this very frustrating, and I must admit, I was beginning to think that there was something wrong with my Macbook. So I fired up TextEdit and tried using the auto repeat feature of the keyboard there.
What I discovered was, certain keys allowed repeated input (turns out mainly only symbols), some keys (certain letters and all the numbers) just sent a single keydown event to the application and others showed a popup:

Apples useful character selector
So I found out what was happening, turns out that Apple had changed the behaviour of my keyboard to make it more iOS like. In normal day to day use, this would be fine: it's not often I need to write a string of repeating characters. However, for the development work I was doing, I didn't want to see this behaviour. Now, being a normal(?), rational person, I thought that I would find the solution to my problem in System Preferences. Surely Apple would have allowed quite a fundamental change to be toggled on or off there. But no, I could not find anything that would allow me to change this behaviour.
Next port of call... Google. After a quick search, I discovered another blog post, this one by Adam Dachis, over at Lifehacker. In that post, Adam describes the very same issue I was having, although it looks like it has been in existence for at least five years.
Adam also gives a very nice Terminal command that can turn this feature off (for those of you that are not familiar with Terminal, it can be found in Applications->Utilities):

defaults write -g ApplePressAndHoldEnabled -bool false

It is also possible to re-instate this behaviour by changing the 'false' to 'true':

defaults write -g ApplePressAndHoldEnabled -bool true

Once you have issued either of these commands, you will nee to re-open your window that you are using to type into as it needs to be initialised with this new setting.
I understand why Apple have made this change, not only does it merge the behaviour of iOS and OS X, but in an increasingly global society, it is nice to have easy access to these characters. However, I do think that they made a mistake by not allowing users to turn this off, or on, whenever it is required.

Monday, 17 August 2015

String Extensions

Like many programmers, I find myself adding and removing characters from either the end or the beginning of strings a lot. It's a simple process, to add to the end of a string, we use:

// s = original string, containing "Hello World"
// n = new value to be added containing "!"
s = s + n //s now contains "Hello World!"

or to add to the beginning of the string, we can just as easily write:

s = n + s // s now contains "!Hello World!"

Retrieving and removing the end, or beginning, of a string is a little more complex, but still very straight forward.
For example, to get the last character from a string, and then removing it can be accomplished by:

// Assumes that s is a string that contains "Hello World"
v = s.Right(1) // v now contains "d"
s = s.Left(s.Len() - 1) // s now contains "Hello Worl"

And to get the first character, whilst removing it, we can use:

// Assumes that s is a string that contains "Hello World"
v = s.Left(1) // v now contains "H"
s = s.Right(s.Len() - 1) // s now contains "ello World"

Simple right?

Why would I need to even address this?

Well, I like simplicity, particularly in my code. I like it to be readable, even if I forget to comment.

To make these simple exercises even simpler, I took a leaf out of Javascript's array handling.
In Javascript, we have four methods for adding and removing items from the ends of an array: push, pop, shift and unshift.

pop and shift remove and return the last or beginning, respectively, element in the array whilst also removing that element from the array.
push and unshift will add the passed elements (yes, you can pass more than one) to the array, either at the end or the beginning.

So, I took this and applied to to the string type in Xojo, with a slight enhancement:
I didn't want to create a subclass the string type (in fact, Xojo won't allow you to do that anyway), so I decided to extend it, with the Extends keyword (as I showed in Extending The Date Class). Although it is not possible to subclass the intrinsic data types in Xojo, we are able to extend then, adding methods as we would for a class.

First off, I'll show you the Pop and Unshift methods:

Sub Push(Extends ByRef s As String, Value As String)
  s = s + Value
End Sub

Sub Unshift(Extends ByRef s As String, Value As String)
  s = Value + s
End Sub

As the eagle eyed amongst you have noticed, I have included the ByRef keyword as well as Extends. This allows us to affect the object, or datatype, being extended. If we didn't use the ByRef keyword, then any changes we made to the datatype would be lost when we exit the method.
Now, if I want to append something to a string, I can simply use the following:

// Assuming s = "Hello" and v = " World"
s.Push(v) // s now holds "Hello World"

Or we could do this:

// Assuming s = "World" and v = "Hello "
s.Unshift(v) // s now holds "Hello World"

To compliment these methods, I created the Pop and Shift methods. These, however, work a little differently to the Javascript originals. Normally, Pop and Shift return a single element from the Javascript array, however, as I sometimes need to get the first 2, or more, characters from the string, I have made these functions accept a parameter that allows me to specify the number of characters to retrieve:

Function Pop(Extends ByRef s As String, NumChars As Integer = 1) As String
  If NumChars < 1 Then NumChars = 1
  
  Dim ReturnValue As String = s.Right(NumChars)
  
  s = s.Left(s.Len() - NumChars)
  
  Return ReturnValue
End Function

Function Shift(Extends ByRef s As String, NumChars As Integer = 1) As String
  If NumChars < 1 Then NumChars = 1
  
  Dim ReturnValue As String = s.Left(NumChars)
  s = s.Right(s.Len() - NumChars)
  
  Return ReturnValue
End Function

Again, we are paying the extended string by reference. This is because we are removing characters from the string. The methods also return the removed characters. So, no if I want to get the last two characters of a string, and remove them from the original, I can use:

// Assuming s contains "Hello World"
v = s.Pop(2) // v now contains "ld" and s contains "Hello Wor"

If I wanted the first two characters, I would use:

v = s.Shift(2)

I have given the NumChars parameter a default of -1. I have also put conditions in the method to prevent the methods receiving a value for NumChars less than 1.

If I only want the first character, I can omit the NumChars parameter all together:

v = s.Shift()

and if I only want the last character, I can use:

v = s.Pop()

I don't know if you'll find these methods useful, but I find they save me a little typing and make my code a tad bit more readable.

If you would like to use them, feel free. Either copy and paste the code form here, or you can download them from here.

One small caveat, I use Xojo 2014 r2.1, which doesn't have the new framework. This may already be in the new framework, or this code might have issues. If anyone would like to test it in a later version of Xojo and let me know, I would be grateful.

Monday, 27 July 2015

BASIC or not?

Since my last post, there has been a discussion on the Xojo forums about the things I said. Most of it has been very positive, and I am grateful to the responses and subsequent discussion that has arisen. However, there is one thing that has been mentioned a couple of times that I would like to address, and I want to do it here as it could possibly clarify what I said before.

Some people think that I should not refer to the underlying language of Xojo as BASIC, and that is a fair point, it is no longer strictly BASIC, but it does have it's roots in the language. Hell, it was once called RealBasic.

Xojo, in my opinion, is an evolution of the BASIC language. BASIC, for those that don't know, is an acronym for Beginners All-puporse Symbolic Instruction Code. This does not mean that is is only for beginners any more.

It was originally design in 1964 as an easier language for non-programmers to be able to create software for mathematics and scientific pursuits. It then became the favoured language for home computers during the 80's during the boom in the market with most home computers having a BASIC interpreter either built in or available as a cartridge add-on (notable exception being the Jupiter Ace, which used Forth).

At that time, the language was fairly limited in what it could do, and the structure of the language also meant that without careful planning, the code could become rather unwieldy and unmanageable. However, the popularity of the language meant that developers continued to evolve it. This involved adding proper functions and subroutines, custom data types and now full object oriented features.
So, the BASIC of today is now very different to the language first developed in the 60's, but does that mean that it is no longer BASIC? Personally, I would argue that it IS still BASIC. The language retains a lot of it's roots, and unlike some other languages, whilst there are some ANSI standards for the language, BASIC developers have always added their own quirks to the language.

In conclusion, I think that Xojo (the language) is BASIC in the same way that the language of Delphi is Pascal. Both have their roots in their respective original languages, but both have exceeded the originals.

Does this make Xojo any less desirable, useable or important? Not at all, today it is a very capable and strong language.

For more information about the origins of BASIC, take a look at Wikipedia

Monday, 20 July 2015

Why Xojo?


Why do I use Xojo?

When talking to my peers in the software industry and they ask what I primarily use for application development, I get a number of reactions when I tell them Xojo. At first I normally get a response that indicates that they have never heard of Xojo. After explaining what it is, the next question is "why not use the standard tools, such as Objective-C for OS X or Visual C++ for Windows?".
In order to answer these questions, let me first give you. Brief history as to how I discovered Xojo. 

When I switched to a Mac, back in 2006, I had come from a Delphi development background. I had just spent the last three years using nothing but Delphi for virtually all of my software. However, making the switch from Windows meant that I needed to find a new development system. At the time, I was not aware that OS X came with developer tools (possibly it didn't, but I'm not sure). So I started to look for a Delphi equivalent for Mac. That led me to Lazarus, the FreePascal IDE that was purportedly cross platform. Unfortunately, at that time, Lazarus required X11 to be installed for OS X, not only for development, but also on the target machine. This was not really acceptable to me, so I moved on. 
My next find was RealBasic. Having also worked with Visual Basic in the past, I was intrigued by this system. RealBasic was supposed to be cross platform, using native controls and allowed for rapid development. I could write on a Mac and compile for Linux, Windows and Mac without the need to use a non-Mac computer. So, I bought a licence.
RealBasic has since been renamed, twice: Firstly to RealStudio, and now Xojo.

Since then, I have also brought my skills for Objective-C and, Apple’s new language, Swift up to date and can comfortably use these. Lazarus has also ditched the requirement for X11, so that is no longer an issue for me.

So why am I still using Xojo?
I think the best way to explain would be to list the pros and cons, that I have discovered, regarding the language:

Cons:
  • It is not free. Unlike Xcode (for Swift and Objective-C) and Lazarus, Xojo is not free and requires the purchase of a license for development (rather, I should say, for distribution, Xojo, Inc do allow you to download the IDE for free and program away, but to create stand alone binaries, you do need a license).
  • It is slow. Actually, that’s not a really fair statement. What I should say, is that applications written in Xojo do not perform as quickly as application written with the official tools. However, most of the time, that is not an issue, the only time I have encountered a problem with speed was with a very graphic intensive application.
  • It’s not as widely supported. As it is not one of the more common languages out there, resources can be a little difficult to find.
  • Not all platform features are supported. This needs qualifying. Not all platform features (Windows, OS X or Linux) are supported “out of the box”. However, Xojo does allow access to the platform API’s. Which does bring me on to my next point…
  • Xojo, Inc are always playing catchup. This does seem like an odd thing to say, but it is true. As this is a third party development system, the Xojo team can only address new features AFTER they are announced. 
  • Fiddly submission to the Mac App Store. With Xcode, I can submit apps to the App Store with very few clicks. However, to do this with Xojo, I either need to go to the command line, or use a third party tool, such as App Wrapper.

That’s a few cons, and for some people it might be enough to turn them away from Xojo. But now we get to the pros:

Pros:
  • Cross platform development. Even though I mainly develop for OS X, having the ability to recompile the same source for Windows or Linux is a blessing. I have even been commissioned to write a Windows application in the past, all of which (besides final testing) was done on my Mac.
  • Native controls. Whether you are on Mac, Windows or Linux, Xojo will mostly use native controls. There are some that are not (e.g. Listbox), but most of the time, it is very hard to see any difference.
  • Fantastic community. I know I mentioned in the cons about the difficulty in finding resources, however, when you do find those resources, they are normally excellent and well supported. Not to mention the very active, and friendly, Xojo forums.
  • API access. As I stated above, Xojo allows you access to all the API’s of the operating system. On OS X, this includes the frameworks. Whilst it can be fiddly, it can be done.
  • The debugger is easy to use. I know this is an odd “pro” to include, but after having used the Xcode debugger for a couple of projects, I have really come to appreciate the Xojo debugger.
  • Rapid development. I can create an application in a couple of days that could potentially take me a week in other languages.
  • Easy to understand. Whilst I know that BASIC is not everyone’s cup of tea, and I also know that some still see it as a “toy” language, I find the syntax very easy to read. This is also one of the reasons I used to use Delphi over C++, it’s just easier to read, and therefore debug.
  • Xojo promotes good programming. What? How did that get here? But it’s true. Because there are times when an algorithm can be very processor intensive, this can slow the application down. I addressed this in the past by re-writing apps in Objective-C, however, with some careful planning and clever coding, Xojo can perform the required tasks at the required speed. So in this way, it does promote better programming.

That’s just a few of the pros and cons. I could list a lot more, and I am sure I have missed some that other Xojo users would have included. In my opinion, most of the cons can be negated by programming techniques, careful planning, or (in the case of App Store submission) inexpensive third party applications.

I know that Xojo is not for everyone. There are times when I will use Swift or Objective-C for a change, but it is a very useful tool that shouldn’t be overlooked in the industry.  
The upshot is if the end application works and does what it’s supposed to, does it matter what language is used?

Tuesday, 11 March 2014

New Xojo version 2014 r1 Is Out

Good news for Apple developers using Xojo. Version 2014 r1 has been released. This version apparently addresses the Quicktime and QTKit issues when submitting apps to the App store.I have yet to try this myself, but from what I hear, things are working great.
What does this mean for me and Krazy Pengwin Games? Well, this means that I can produce applications in a much tighter time scale. Whilst working directly with Objective-C and Cocoa was an eye opening experience, and one which I surprisingly enjoyed, using Xojo will speed up development ten-fold. There are certain things in Cocoa that I will miss in Xojo (bindings and speed in particular), but I think the speed of development and the ease of code maintenance will outweigh those for most projects, as will the SQLLite integration. I am sure there are times when I will need the speed of native programming, in which case I will go back to Objective-C, but at least, after this learning experience, I have the choice now.

Thursday, 13 February 2014

Don't Leave Bad Reviews If...

... the issue can be corrected.
Just wanted to share a recent experience I had with a game I downloaded from the Amazon App Store onto my Kindle Fire.
One of my favourite Facebook games is Monster Busters (I know, I should be working instead of playing games), so imagine my delight when I saw that it was available on the Amazon App Store. Off I went and downloaded it. Whilst downloading, I read the reviews that had already been posted, most of which were fairly negative, because of an issue with logging into Facebook. Still, I’ve read things like this before and not had problems with other apps, so I carried on with the download.
Unfortunately, the comments made were right. The game would not access Facebook, and it needed to in order to sync with my account.
However, rather than leave a negative comment, on what I was sure was a good game, just with a slight issue preventing me playing it, I contacted the makers of the game, PurpleKiwii, and reported the issue. After all, a negative comment can, and does, affect future sales (I know this is a free game, but it’s still not nice to have negative reviews on any of your projects).
The next day, I got a email back from PurpleKiwii, thanking me for my report and letting me know that the issue has now been fixed and available on the Store.
So, what I have to say is, please do not leave negative feedback straightaway if the issue you have is a bug or failing feature. It may be that something beyond control of the developers has changed (I’m not saying that it is the case in this instance, but it is a possibility). It is equally possible that something may work on the developers machine, but for some reason doesn’t work on others. Things DO slip through testing processes from time to time, it’s a way of (developers) life. It is much better to report an issue to the developer and get them to fix it, rather than do without the product all together and leave a review that could impact on the developers future sales.
Anyway, that’s all I have to say, and thank you PurpleKiwii, 10/10 for customer service, but you have now halved MY productivity as I do ‘just one more level’.

Saturday, 1 February 2014

Crash Course In Objective-C

Due to Apple’s policies throwing Xojo, inc a curve, I have decided that in order to get some of the smaller applications out I should rewrite them in Objective-C.
I didn’t realise what a steep learning curve this could present.
I have recently released Image Slicer on the App Store, completely rewritten using Apples tools, rather than Xojo. It didn’t take as long as I thought it might, but it was still a challenge, particularly as I have only dabbled with Objective-C before, not really creating anything useful.
The crash course began on Saturday, 25 January, and I was able to submit the initial binary by Monday evening. Unfortunately, I was a bit overzealous with the sandboxing allowances, so it was rejected a couple of days later. But a quick update (and a few other tweaks), and it was submitted again on Wednesday. Two days later, I got the approval email from Apple.
Although this has proven to me that I CAN used Objective-C for my Mac applications, I will probably go back to Xojo after Xojo, inc have addressed the issue preventing apps created in it being accepted by Apple for the App Store, so that I will be able to offer Windows versions as well as Mac versions.