Monday, November 26, 2012

Speeding up TextArea modifications under Cocoa

When doing a lot of manipulation to a TextArea's contents under Cocoa, performance can suffer due to the underlying NSTextView doing work on layout and glyph selection. This can be sped up by telling the text view that you're going to begin editing. You can do this by using a few Cocoa Declares.

The Declare statements are relatively simple:

Declare Function documentView Lib "AppKit" Selector "documentView" ( obj As Integer ) As Integer
Declare Function textStorage Lib "AppKit" Selector "textStorage" ( obj As Integer ) As Integer
Declare Sub beginEditing Lib "AppKit" Selector "beginEditing" ( obj As Integer )
Declare Sub endEditing Lib "AppKit" Selector "endEditing" ( obj As Integer )

These Declares give you access to methods for enabling "batch-editing mode" for the underlying NSTextView.

First you want to get the text storage for the document, which is a two-step process. In the first step, you take the TextArea's Handle property (an NSScrollView instance) and ask for its document view:

Dim docView As Integer
docView = documentView(MyTextArea.Handle)

Now you get the NSTextStorage for the NSTextView:

Dim storage As Integer
storage = textStorage(docView)

With the text storage, you can now enable batch-editing mode by calling beginEditing:

beginEditing(storage)

Now you can make your significant changes to the TextArea:

For i As Integer = 0 To 5000
  MyTextArea.AppendText("Lorem ipsum dolor sit amet. ")
Next

And when you are finished disable batch-editing mode:

endEditing(storage)

So how much does this improve performance? In my tests, the For loop by itself takes about 4.3 seconds to complete. Using batch-edit mode with these Declares drops it to 0.02 seconds. That's almost instantaneous!

If you find you are going to use these Declare 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.

Tuesday, November 20, 2012

A Possible Issue Running Console Apps from Real Studio

On OS X 10.8.2 you may run into an OS X bug in how Apple Events are handled.

When you try to run a console application in debug mode using Real Studio on OS X, the IDE sends an Apple Event targeting Terminal to run your debug app inside a terminal window. On 10.8.2 there is a system process that mediates the sending of Apple Events to other processes (such as Terminal).


Unfortunately, sometimes this system process gets "stuck" such that the IDE never gets a reply that the console application was launched. This means you may have to Force Quit the IDE.


Sadly it's unpredictable as to when or if this process will do this.


If you do a Google search for "10.8.2 appleeventsd" you will find this bug in OS X mentioned in a number of places.


You can read about it on a few blogs that have noted this issue: A workaround for AESSendMessage hanging on OS X 10.8.2


This bug has already been sent to Apple: http://www.openradar.me/12424662


It's also being discussed on the relevant Apple Developer Forums https://devforums.apple.com/message/744795 (Pay attention to the posts by Eskimo1)

Should this problem occur for you, it appears that killing the appleeventsd daemon using Activity Monitor will fix the issue temporarily.


Hopefully this is something that Apple will be able to address in the next update to OS X 10.8.


Gotcha's when porting Visual Basic Code to Real Studio

The other day we got an interesting and initially puzzling bug report from a user who was porting a fairly large project from Visual Basic to Real Studio. Initially the error message didn't seem to make sense to me or Jason in Tech Support.

Our first step was to make up a simple example project. Once we had managed to trim things down to our example project and we could reproduce the error, it all made perfect sense. 

Our example started with a new desktop project, we put two pushbuttons on the default window: PushButton1 and PushButton2. In the action event of Pushbutton1 we put:

         PushButton2_Action

In PushButton2's action event we put:

         msgbox "hello world"

Run the project and you will get an error that says:

   This method requires more parameters than were passed

THis is odd since there's no method anywhere called "PushButton2_Action". However, in our example the error tells you precisely where to look:

Window1.PushButton1.Action, line 1, This method requires more parameters than were passed, PushButton2_Action

In Visual Basic you could call the "action" event of a push button just like any other method; and the name was very predictable. The action event was named:

ControlName_Event

And it may or may not have had parameters that got passed to it. And if you grab a Visual Basic project and port it Real Studio you may still have this kind of code left over.

So how do you find this kind of left over code in ported VB projects? 

I have to admit that in a big project that is going to be a big job. If you know the old code base, you might hunt for control names followed by a _ . So in our sample you might look for "PushButton2_" and then deal with all the items you find since this syntax is unlikely to be valid in Real Studio. Or you might hunt for the "_Action" or other names that were used in VB to call other controls event handlers.

Now that you've found it, what can you do to fix it?

The easiest thing to do is to move the code in the action event handler that was being invoked into a method that can be called from where ever needed. Can you call the event directly? Let's just say that might work but it's unsupported - so don't do it.

In the end, the compiler correctly identified the error but the error message was easy to misunderstand. So when you DO get an error have a VERY close look.

Oh, and leave the VB habits behind :)

Monday, November 19, 2012

Using Web Edition with Google Powered SItes


We’d like to than Wayne Golding for offering the following blog post on his use of Real Studio Web Edition. Wayne found Real Studio when Microsoft announced the end of VB6.  He started out programming in the 80’s implementing accounting/inventory control systems, then moved on to cutting COBOL code (and fixing millennium bugs) in the 90s.  Later he switched to DRNine11 and used Real Studio primarily to develop tools that run on Windows Servers as Services. Now he uses Real Studio Web Edition in nearly 100% of his projects.

------------

Hi All,

Today I’m going to show you how I use Real Studio Web Applications with my Google Sites powered website.  In the image below you can see a typical contact page.  What’s different is that the contact form is actually a Real Studio Web application running on a server in my datacenter.  In this case it’s a Windows server and the Real Studio Web Edition app is running as a service.


So how do I do this?


Well, first I insert a gadget into my web page, then I select More Gadgets and search for iframe.



 And Select it.



I MUST give the URL content which will be HTTP://<yourdomain>/<yourwebapp>.cgi  and links to your Real Studio Web Application.

If you don’t want scroll bars, then set the width & height to match those specified in your Web Application.

I prefer to provide my own title so I untick the Display title on gadget checkbox.

And that’s it! Simple!

With the form shown, I also send the email to myself using Gmail along with logging the message in a MySQL database.

This is all done from within my WE Application, but could be done from any Real Studio application.

First in my Project.App I create a property:

theMailServer As SMTPSecureSocket

In my Project.App.Open I initialise this object

theMailServer = New SMTPSecureSocket
t
heMailServer.Address = "smtp.gmail.com

theMailServer.Port = 465

theMailServer.Username = <your gmail username>

theMailServer.Password = "<your gmail password>"

theMailServer.ConnectionType = SMTPSecureSocket.SSLv23

theMailServer.Secure = True

It’s important that this is instantiated in the App object as we’ll be using asynchronous communication.

In the Action event of the submit button I will send the message.

Dim msg As New EmailMessage

msg.AddRecipient “<my address>”

msg.subject = Subject.Text

msg.BodyPlainText = Message.Text

App.theMailServer.AppendMessage msg

App.theMailServer.SendMessage

You’ll note there is no msg.FromAddress as this is replaced by the Username supplied to when logging in. And that’s it folks – a Real Studio Web Application integrated into Google Sites & emailing via Gmail.


Thursday, November 15, 2012

Where's the Super?

As projects get bigger, you probably start organizing them items into folders. This makes keeping track of your project easier but it can also make some things more difficult to find. For example, when you are examining a canvas subclass, a container control or a webdialog on a layout and need to look at the original project item digging through your project to find it can be time-consuming.

Fortunately, there's an easier way. Just right-click on the item on the layout (or in the tray in the case of web dialogs) and choose "Edit Super Class" from the contextual menu. This will take you right to the parent item which is its super class.



If you haven't spent much time investigating the various contextual menus, it's worth the effort. There are several great shortcuts in them.

Wednesday, November 14, 2012

Win32, and WinRT, and WPF oh my!

Like any modern operating system, Windows is constantly evolving.  However, it still maintains a high level of backwards compatibility, which is great for many legacy apps that consumers depend on, which in turn is great for developers, consumers, and the framework that your apps are built upon.  With all the jargon floating around it's time to clarify where our Windows framework stands today.

Managed vs. Unmanaged code
Simply put, our Framework is unmanaged code, which means no .NET framework is required to run apps built with Real Studio.

WinForms vs. WPF vs. Win32 controls
These are the presentation layers that Windows supports.  WinForms (or Windows Forms) is part of the .NET framework, and most of its controls are based off of the lower level Win32 controls API.  WPF (or Windows Presentation Foundation) is also part of the .NET framework, it is a newer presentation layer whose controls are built on top of a different rendering engine to take advantage of modern GPUs.  Win32 controls is the unmanged, low level GUI API that has survived the ages.  This is what our Windows framework is built on top of.  There are various pros and cons to each framework, but to understand why our controls behave the way they do it helps to know what presentation layer our framework uses.

WinRT vs. Win32
You may have heard of WinRT as the new Metro-style framework for Windows 8.  This runtime framework includes a new set of controls designed to create Metro-style apps.  Since our framework is built upon the Win32 API, you will not be able to build Metro-style apps in Real Studio yet.  Note: this does not mean you cannot build apps today that run on Windows 8 Desktop.

Interoping
The nice thing about these frameworks is that most of the functionality is interoperable.  In other words, I can use the WPF controls from an unmanaged framework (i.e. our Win32 framework), and vice versa (with some limitations of course, for example, WinRT's framework has some restrictions between what you can use on Desktop vs. Metro-style apps).  As an example to demonstrate this interoperability, I've built a plugin for Real Studio which embeds a WPF Spell Checking TextArea-like control that can be used in a Real Studio app.  Since I'm using managed code, the .NET framework is now required if I were to distribute this app to users.


Of course this plugin is merely a proof of concept and not ready to be distributed, sorry. :)

Tuesday, November 13, 2012

The Schedule for 2012 R2 and 2013 R1

Everyone here continues to work hard on the new IDE and we think you're really going to love it. Feature development is done but there are still bugs that need to be fixed. We plan for a much longer testing cycle to make sure that the new IDE is solid before we ship it.

That said, we know you depend on us for regular updates. We have fixed a lot of bugs and added some nice new framework features since our last release. So in order to get you an update and have adequate time to test the new IDE, we are going to change the schedule a bit.

Today we are releasing 2012 R2 beta 1 to our beta testers. This is the current IDE with the updated framework. Real Studio 2012 R2 will ship in December.

Today we are also releasing 2013 R1 alpha 1 to our alpha testers. This release includes the new IDE and will move to beta around the end of the year. Assuming testing goes well, we will ship 2013 R1 sometime in the first quarter of next year. The previously announced pricing change will take effect with the release of 2013 R1.

The new IDE for OS X is a Cocoa application. This part of our criteria for changing the Cocoa framework from beta to shipping: shipping an IDE built with the Cocoa framework. So beginning with 2013 R1, Cocoa will no longer be beta and will be the default build framework for OS X applications.

2012 has been an unusual year for us. From 2005 through 2011 we released every 90 days. We expect to be back on our regular, quarterly release schedule in 2013.

Again, we want the new IDE to be solid and that means taking some extra time to get it right. Your patience is appreciated.

Monday, November 5, 2012

Getting More From Feedback

You may not be aware of this but our Feedback app has a new search engine that is much better than the old one. Now, the more words that you search for the better the result will be. For example, consider the results after searching for "pushbutton action":


When searching Feedback, make sure you use as many words as adequately describe the issue. That will result in a higher probability of finding the case if it's already been reported. Duplicate reports slow down our ability to fix bugs and such so finding an existing report rather than creating a new one helps everyone.

Feedback Rank plays a big part in how we prioritize what bugs to fix and what features to implement in Real Studio. This list is your opportunity to tell us which bugs and feature requests are most important to you. Remember to review your Top Cases in Feedback from time to time to make sure that the list is up to date. Some of the items in your list may have been fixed or closed. In those cases, you'd want to replace them with other unresolved cases that are important to you.


For the most part, we fix bugs and implement features based on the impact the case has on the user community as a whole. If you find that a case is not being addressed (perhaps it's impacting you, but may not be effecting many other users), contact us.

You can find more Feedback Hints & Tips here.