NilObject

A few weeks ago, I came into work greeted with a sticky note reading, “You own the registration code now.” Oh, goody!</sarcasm>

Well, I sat down this morning and coded for three full hours without a single run. The window had been designed, but needed to be integrated and coded. Since the code already existed in the main project, just needed to be refactored and some rewritten, it was time to integrate the external project into the IDE. Because of the size of the REALbasic 2005 project (now over 110k lines), it takes a long time to compile, and it made me defer running until I actually had 95% of it done.

Surprisingly, it mostly just worked. A nice delight after coding for that long. Time to put the final tweaks into it.

3 Comments »

So, I was just working away, using the dynamic access in the plugins SDK, and got an error on this line:

REALSetPropValue( item, “Enabled”, true );

The reason is that there are three REALSetPropValue functions that it could possibly be, because of the weakness of types in C. The exact error was:

Error : ambiguous access to overloaded function
‘REALSetPropValue(REALobjectStruct *, const char *, unsigned char)’
‘REALSetPropValue(REALobjectStruct *, const char *, long)’
‘REALSetPropValue(REALobjectStruct *, const char *, double)’
BrowserCarbonImplementation.cpp line 326 REALSetPropValue( item, “Enabled”, true );

Ok… so the fix? That’s right, typecast “true” to Boolean:

REALSetPropValue( item, “Enabled”, (Boolean)true );

Boy, I like REALbasic more and more each time I see something like this

No Comments yet »

So, I’m working on the third or forth implementation of a Wizard-style interface, and I figured it would be a great topic, because I’m pretty fond of my design. Wizards are often step-by-step mechanisms to guide you through a process. For example, an installer is a style of Wizard, and the new license dialogs in REALbasic 2005 will be Wizards now.

Because of the nature of Wizards, you have a lot of controls and a lot of logic on one Window. In REALbasic 2005, a good idea for an implementation would be a set of ContainerControls sitting on each page of a PagePanel. It ensures that you extract the logic enough so that each page only knows about what it needs to know about (no cheating!), and the Window simply coordinates each page.

However, for simple Wizards, that’s overkill. In either case, here’s a few pointers that I have found work really well when designing a Wizard-style window:

• Create integer constants on the Window (Edit-New Constant) for each page, and name them descriptively. Then, don’t ever assign to PagePanel.Value without using a constant. This has two benefits:
  1. If you decide to insert a page, or add a page, you don’t have to go updating your code — just your constants
  2. It makes it easier to read the logic of your code. E.g. “If the user is at the enter license key page, and they press back, they’re going to go to the first page.”
• Create a pair of methods: NextPage( page as Integer ) as Integer, PreviousPage( page as Integer ) as Integer. These are generally just select case statements, but also can contain more logic, such as if the user is asking for a demo key and requesting to be on the tips mailing list, it should go to page X. Make sure to use your integer constants! Return -1 if there is no next/previous page.
• The next and previous buttons should be very simple:

  Dim newPage As Integer
  newPage = NextPage( panel.Value )
  If newPage <> -1 Then
    panel.Value = newPage
  End If
  

• The page changing code should be very simple as well. In the ValueChanged event of the PagePanel:

  NextButton.Enabled = (NextPage( me.Value ) <> -1)
  PreviousButton.Enabled = (PreviousPage( me.Value ) <> -1)
  

• Finally, try to make your state be properties on the window. For example, if the user is requesting to be on the Tips mailing list, set a boolean flag — don’t just check the checkbox’s state. This makes it easier to swap pages out in the future.

While these tips aren’t required, they are generally going to help with your Wizard. I’ve never had a Wizard that I haven’t had to go back and change many times, deleting pages, adding pages, or reording the logic. The more you follow those tips, the easier it will be to redesign sections of it with minimal impact.

No Comments yet »

Well, as is usual with this time of the release cycle, it’s rampant bug squashing time. I’ve lost track of how many bugs I’ve fixed in the last couple weeks. However, none of them are nearly as satisfactory as the one I squashed last night after work.

So, the compiler for REALbasic currently aligns data to 4-byte offsets because there was a bug somewhere in the compiler that was generating improper code when doing alignment of types that weren’t a multiple of 4 bytes. The general rule used in most languages and compilers is that a type is aligned to it’s natural size. So, if you have a double (8 bytes), the compiler will make sure to put it on the stack at a multiple of 8.

Well, I’ve been toying with the idea of adding something that would require more precise data alignment, but when researching it, I saw the comment that basically said, “Don’t have time to figure it out, please come back and fix me.” Worried that such a bug might be the difference of me implementing said feature, I sat down last night after work to do what the comment requested: fix it.

After an hour and a half, several disassemblies of the built REALbasic apps, and many reworkings of a sample project, I finally found the bug and sqaushed it. While the feature I’m contemplating may never see the day, data alignment is a very big thing. Check out Jonathan “Wolf” Rentzsch’s data alignment article (and follow-up) for more details on why data alignment is great for speed. It’s a very interesting read, and I’ve been meaning to come up with a reason to point out the article. I finally came up with one

No Comments yet »