From my “Making Better Examples” series (xDev 14.2 p33):
I’m always on the lookout for nice tips for the Tips & Tricks column, so from time to time I go over all the latest Xojo related blog posts that I know of. So on the Xojo blog I came across a tip from Joe Ranieri on how to speed up text modifications on OS X ( http://blog.xojo.com/blog/speeding_up_textarea_modifications_under_cocoa_reprint ).
It is a good tip, and we had already covered it in a previous issue (see xDev 12.4, Tips & Tricks, Tip 3). It is also a repost of a tip on the old REALsoftware blog from 2012 ( http://www.realsoftwareblog.com/2012/11/speeding-up-textarea-modifications.html ).
On reading it again and wondering why I don’t use it much, I realized something that annoys me about so many tips and examples.
(Now let’s be clear: being annoyed can be a good thing. Because it tells you there is something that can be improved upon and made to be less annoying – you just have to figure out what it really is that annoys you.)
At first I thought it was the following sentence, which I already moaned about it in 2012 when I pointed out the following as not being beginner-friendly:
If you find you are going to use these Declares often, you might want to add them to a module as Extension methods so that you can call them more easily, which I’ll leave as an exercise for the reader.
Now extensions are easy, I grant you that. But so is separating eggs (see Figure 1). Or braising beef. Or doing a restriction digest or running a PCR.
But keep in mind: Many things are only easy if you already know what they are and/or how to do them . For example, I had to look up what braising actually means as I was not familiar with the term.
The same can be said for beginners and extension methods. Yes, that’s generally what people call learning, but bear with me. Because that’s not what caused my annoyance.
Joe obviously took my complaint about being nice to beginners to heart as the new Xojo blog post contains an example project, and in it he includes the extension methods he alluded to in his original post on the REALsoftware blog.
But look at the final code for using the extension methods in Figure 2. Can you spot in the screenshot what annoyed me and caused my epiphany?
Go on, have a close look. And no peeking at the text further down.
No? You don’t find anything annoying about the code in this tip? Nothing you would want to change or improve?
If I should summarize in one word what annoys me here then I would say it’s the usability of the tip. For one thing it is the Dim statements. Am I really supposed to remember to type
Dim docView As Integer = ExampleTextArea.DocumentView
Dim storage As Integer = ExampleTextArea.TextStorage(docView)
every time I want to use fast editing? I do have a bad memory, so while I might remember the existence of a fast edit mode (and auto-complete really comes in handy here), I would have to look up the code each time (and most likely copy/paste it). Furthermore, the dim statement requires the passing of a parameter (storage) to the extension method. Is this really necessary? And finally BeginEditing is far too non-descript for my liking as it doesn’t convey the purpose of the extension method. Why not BeginFastEditing instead?
Wouldn’t this speed-up tip be so much easier to use, not to mention be more concise and elegant, if we could simply write:
ExampleTextArea.Text = ""
ExampleTextArea.BeginFastEditing
FillTextArea("Lorem ipsum ")
ExampleTextArea.EndFastEditing
Of course it would. And it’s easy to do too. All you have to do is move the Dim statements into the extension methods, rename them, and remove the storage parameter from the extension method declarations. So this
Sub BeginEditing(Extends ta As TextArea, storage As Integer)
#If TargetMacOS Then
Declare Sub beginEditing Lib "AppKit" Selector "beginEditing" ( obj As Integer )
beginEditing(storage)
#Endif
End Sub
becomes this:
Sub BeginFastEditing(Extends ta As TextArea)
#If TargetMacOS Then
Dim docView As Integer = ta.DocumentView
Dim storage As Integer = ta.TextStorage( docView )
Declare Sub beginEditing Lib "AppKit" Selector "beginEditing" ( obj As Integer )
beginEditing( storage )
#Endif
End Sub
and
Sub EndEditing(Extends ta As TextArea, storage As Integer)
#If TargetMacOS Then
Declare Sub endEditing Lib "AppKit" Selector "endEditing" ( obj As Integer )
endEditing( storage )
#Endif
End Sub
becomes
Sub EndFastEditing(Extends ta As TextArea)
#If TargetMacOS Then
Dim docView As Integer = ta.DocumentView
Dim storage As Integer = ta.TextStorage( docView )
Declare Sub endEditing Lib "AppKit" Selector "endEditing" ( obj As Integer )
endEditing( storage )
#Endif
End Sub
Note to beginners : since this is an extension to a TextArea, you do not need to pass the TextArea as a parameter as you would with a normal method. The extension method already specifies which TextArea to use: the one ( ta ) calling the extension.
But does moving the Dim statements into the extension method not impact negatively on the speed of the extension method? In my tests I called both versions of the extension method 5,000 times but saw no significant difference between them. But feel free to play around with the little test app I made (see Figure 3) – you can also enable/disable pragmas, or use styled text, and see what a difference that makes.
