Angelo Computers - realbasic gems

REALLoadGlobalMethod doesn't do what you might think

Thu, 21 Feb 2008 21:29:49 +0000

The duty of this API is to load up global framework methods. That's it, and nothing more. It does not, cannot and will not load up anything outside of the select handful of framework functions that we provide. This is a problem because the name of the API certainly doesn't imply that... and the parameter signature of the function exacerbates the issue by providing a parameter to specify what module to load the function from!

REALLoadGlobalMethod doesn't do what you might think

Thu, 21 Feb 2008 21:29:40 +0000

This topic came up recently on the forums, and so I figured it might make a bit of sense to discuss what REALLoadGlobalMethod is. It's a plugin SDK function that is part of the dynamic access set of APIs. However, it's also total misnomer, as it's job is not to load up global methods like you might think. The duty of this API is to load up global framework methods. That's it, and nothing more. It does not, cannot and will not load up anything outside of the select handful of framework functions that we provide. This is a problem because the name of the API certainly doesn't imply that...

Little-known datatype fact

Wed, 20 Feb 2008 17:00:40 +0000

REALbasic used to have some datatypes which were only legal in declares, like CString and PString -- however, in recent history (several releases back, but I forget when), these became first-class datatypes. This means that you can use them outside of the context of declares. However, their use is quite limited outside of declares, so I'd strongly advise against using them as general purpose datatypes. Just use String if you're not going to monkey with declares. That being said, all of the new string datatypes are essentially a type of Ptr. CString is a pointer to a null-terminated, ANSI C string.

Little-known datatype fact

Wed, 20 Feb 2008 17:00:18 +0000

That being said, all of the new string datatypes are essentially a type of Ptr. CString is a pointer to a null-terminated, ANSI C string. WString is a pointer to a null-terminate ANSI wchar_t string. PString is a pointer to a typical Pascal string (up to 255 characters long). CFStringRef is, crazily enough, a CFStringRef (only useful in Carbon and Cocoa), which is an opaque string pointer. This has an interesting ramification when it comes to declares.

2008r1 Awesome Stuff!

Mon, 11 Feb 2008 17:00:40 +0000

Here's my list of the awesome things I love about 2008r1, in no particular order:

Introspection is rather neat. It's not the coolest thing ever, but it certainly has some nice functionality to it. For instance, I can now create COM interface producers with a little more ease by introspecting an object in order to do the vtable hookups. There are some other awesome things you can do with introspection as well, such as serializing an object in an automated fashion. However, until you're able to create an object by name, unserializing is still kind of painful.
The ability to put anything into a variant, including arrays.

2008r1 Awesome Stuff!

Mon, 11 Feb 2008 17:00:15 +0000

Here's my list of the awesome things I love about 2008r1, in no particular order:

Introspection is rather neat. It's not the coolest thing ever, but it certainly has some nice functionality to it. For instance, I can now create COM interface producers with a little more ease by introspecting an object in order to do the vtable hookups. There are some other awesome things you can do with introspection as well, such as serializing an object in an automated fashion. However, until you're able to create an object by name, unserializing is still kind of painful.
The ability to put anything into a variant, including arrays. Variants used to be handy, but now they down-right rock! This means you can store an array into a dictionary, for instance. So I can finally polish up a really nice preferences class interface!
This is a little feature, but one I still really enjoy. I have a mouse with extra buttons on it for performing common actions like back and forward. I use these buttons constantly while browsing the web, as well as within Windows Explorer. The IDE used to ignore these buttons, but no longer! I can also use some of the extended keyboard buttons for functionality like search, cut/copy/paste, etc. Very minor, but still a really nice thing.
A whole bunch of work was done to make Win32 functionality more Unicode-savvy, which is always great. Since RB only supports Win2k and higher, it's about time to see the last vestiges of ANSI support go away and be replaced with Unicode.
Deprecations and removals! I know that may seem odd to be part of my "awesome stuff" list, but I strongly approve of deprecating functionality which would otherwise be ignored. This opens up the market to 3rd party developers who want to take over and provide that functionality, if it's necessary. It also removes cruft from the RB framework, which is always great.
There's a new compiler feature that allows you to specify that a method implements a particular interface method explicitly. This is useful if you don't care for a particular interface's nomenclature. For instance, let's say an interface exposes a method called WriteError, but you really don't like that as it doesn't fit with your class' API. You can have the class implement a method called SpiffyError which Implements SomeInterface.WriteError instead. This may not seem too useful now, but it has connotations for the future that are very exciting.

What things do you really like about 2008r1? Any particular feature you absolutely adore? Any bug fix you were excited to see taken care of?

Differentials make a difference!

Sun, 10 Feb 2008 03:44:40 +0000

A lot of times, reducing a bug report to the simplest possible example isn't quite enough. The thing that really makes the difference between fixing a bug quickly or not is giving information about what works and what doesn't work. Here's a great example that I culled down from a recent bug report.

 Dim m As MemoryBlock = NewMemoryBlock( 128*4 )  Dim p As Ptr = m  Dim i As Integer = 264  p.Single(i) = p.Single(i) + 2.0  MsgBox Str( p.Single( i ) )

This code would display the value "0" instead of "2", and then crash. However, if you replace every instance of "i" with 264, then the crash would go away.

Differentials make a difference!

Sun, 10 Feb 2008 03:44:05 +0000


 Dim m As MemoryBlock = NewMemoryBlock( 128*4 ) 
 Dim p As Ptr = m 
 Dim i As Integer = 264 
 p.Single(i) = p.Single(i) + 2.0 
 MsgBox Str( p.Single( i ) )

This code would display the value "0" instead of "2", and then crash. However, if you replace every instance of "i" with 264, then the crash would go away. Like this:


 Dim m As MemoryBlock = NewMemoryBlock( 128*4 ) 
 Dim p As Ptr = m 
 Dim i As Integer = 264 
 p.Single(264) = p.Single(264) + 2.0 
 MsgBox Str( p.Single( 264 ) )

That is what I mean by "differential." In one case, it crashes, and in the other case it works.

REALbasic is not C++

Mon, 04 Feb 2008 18:12:52 +0000

One major cross-over feature of all object oriented languages is the concept of a class constructor. The compiler inserts some magical code for you whenever you create a new instance of a class that automatically calls this special function. This way, the programmer can be assured that there is no possible way to allocate a valid class instance without calling this special method. It's perfect for initialization tasks that need to run before everything else.

REALbasic is not C++

Mon, 04 Feb 2008 18:12:40 +0000

This statement should strike you as obvious for many reasons, syntax being the most prominent. However, it does bear repeating on occasion for some of the lesser-known differences between the two languages. At their heart, most OO languages have a lot of similarities between one another. After all, just how many different ways are there to encapsulate data and logic? One major cross-over feature of all object oriented languages is the concept of a class constructor. The compiler inserts some magical code for you whenever you create a new instance of a class that automatically calls this special function.

Complex UIs can lead to "strange" compile errors

Fri, 01 Feb 2008 18:40:53 +0000

The reporter had a complex window, and when they would compile their project, they would get an error complaining about "method uses 37k of stack space, but the limit is 32k". Name: NameOfWindowGoesHere" This may seem like a very confusing error message because the name being reported is a window, not a method!

This goes back to a previous blog posting I made about how windows work within REALbasic. A window isn't just this magical thing that the compiler knows about. In fact, the compiler actually has no idea what a window object is! To the compiler, it's just another class and there's nothing special about it. Everything special derives from the IDE rendering out your window object in a way that makes the magic happen.

Complex UIs can lead to "strange" compile errors

Fri, 01 Feb 2008 18:40:40 +0000

I noticed a bug report came in this morning about an error message that didn't make sense to the reporter. I figured this would make an excellent blog topic, since it explains not only the why but the how to fix it. The reporter had a complex window, and when they would compile their project, they would get an error complaining about "method uses 37k of stack space, but the limit is 32k". Name: NameOfWindowGoesHere" This may seem like a very confusing error message because the name being reported is a window, not a method! This goes back to a previous blog posting I made about how windows work within REALbasic.

VirtualVolume Gotcha

Fri, 01 Feb 2008 02:09:52 +0000

So I had cause to play around with VirtualVolumes for a project today, and I ran into a gotcha that you really should watch out for. It turns out that VirtualVolumes don't play nice with UTF-16 encodings, at least with regards to the file operations. I was getting file paths from the command line, which on NT-based versions of Windows will usually be in UTF-16. I was then using this information to create a folder hierarchy within a virtual volume, and couldn't figure out why my folders were never being created. What was even more strange was that the code worked when the paths were just string constants! Basically, this would work:
someVV.Child( "Test" ).CreateAsFolder
while this would fail:
someVV.Child( commandLineArg ).CreateAsFolder
It took quite a while to track down the fact that it was encodings related because the failure mode was to just silently not create the folder. No LastErrorCode, nothing. The only way I found out there was an issue was because a subsequent call to create a file was returning a nil stream back to me when it shouldn't have. Yikes!

VirtualVolume Gotcha

Fri, 01 Feb 2008 02:09:40 +0000

So I had cause to play around with VirtualVolumes for a project today, and I ran into a gotcha that you really should watch out for. It turns out that VirtualVolumes don't play nice with UTF-16 encodings, at least with regards to the file operations. I was getting file paths from the command line, which on NT-based versions of Windows will usually be in UTF-16. I was then using this information to create a folder hierarchy within a virtual volume, and couldn't figure out why my folders were never being created. What was even more strange was that the code worked when the paths were just string constants! Basically, this would work: someVV.Child( "Test" ).CreateAsFolder while this would fail: someVV.Child( commandLineArg ).CreateAsFolder It took quite a while to track down the fact that it was encodings related because the failure mode was to just silently not create the folder.

RBLibrary.com is under new ownership

Mon, 28 Jan 2008 22:31:39 +0000

Riverside, California (January 28, 2008) - RBLibrary.com is happy to announce the purchase of RBLibrary by Great White Software. "We are proud of providing expert articles about REALbasic to the community, and are excited that Great White Software can continue this tradition.", said RBLibrary co-founder Aaron Ballman. "Great White Software has been providing REALbasic users with excellent software and services for the past ten years and we're pleased to see them continue their commitment to the REALbasic community by acquiring RBLibrary." "We acquired this site so that REALbasic users will continue to have a well-known, trusted, and dependable source of information about REALbasic." stated Norman Palardy, principal of Great White Software.