So I got my brand-spanking new desktop machine today (my old one barely lasted two years before it gave up the ghost), and I thought it would be fun to keep track of everything that I do to get a machine all set up "properly" for my needs. Step 1: reformat. I don't care what machine I get, who I get it from, etc. I always reformat it first thing -- this way, I can be sure the machine is setup the way I want it to be with no happy surprises. Today, I booted my new machine once just
February 2008 Archives
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
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
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
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
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. This
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
