I’m a big fan of the Einhugur control suite for REALbasic. In particular, the Einhugur TreeView, Calendar, Date, and Time controls often find their way into my projects, both internally and for consulting projects. The StyleGrid also gets some consideration for many projects as well.
A recent post on the Monkeybread Software blog mentions a number of bugs about the ComboBox control. I agree with Christian’s assessment of the state of the ComboBox control. I made a comment (currently awaiting moderation) that I thought that a 3rd party could sell a full-featured combobox control.
I’ve mentioned in the past that I would help finance someone to come up with a cross-platform WebKit plugin and, as of yet, no one has made one or approached me taking me up on the offer. REAL Software has indicated that they’re looking at it. Given their workload I’m not sure I expect it anytime soon.
I’m also a big fan of the True North Software Formatted Text Control. I’ve used it in quite a few projects and find it to be a very nice replacement for the the TextArea control. For now, it’s the best way to get true RTF support in your REALbasic application. It’s also very extensible so if you need it to do something special you can modify the source to do it (though it might be a lot of work).
Other things I’d like to see:
- A multi-column popupmenu/combobox
- A grid control that supported container controls hosted in individual cells
- A list view that could switch between column (Mac OS X), TreeView, List, and Icon View.
What is on your wish list of controls for REALbasic that are currently not available? Why isn’t there a bigger market for 3rd party controls?
There is a thoughtful blog post from Mattias Sandström on the Association of REALbasic Professionals site. (Direct Link)
I think it fits in rather well with my post back in May about the REAL Software beta process. Mattias’ standpoint as a user of a lot of other IDE’s is well taken. I really like the idea of polling the beta users about the release. I wish it was possible to ask about every change but I know that’s not feasible but the number of bugs that were marked as fixed but were obviously not in the past couple of releases is insane. There has to be a better way!
I would agree with Mattias regarding the beta mailing list. I find it to be waste of time and energy. I prefer forum style discussions.
Here is my prediction though, if RS tried to switch to the forums: Instead of using the forum, the RB “old-timers” will insist upon the mailing list because they feel it’s better. How do I know this? When RS tried to kill the NUG mailing list a few years ago the “old-timers” threatened to create their own mailing list and many threatened to stop using RB altogether! In the long run RS backed down and I lost a lot of respect for RS and the RB community as a whole. They were being held hostage by a very select and vocal group of users.
For the beta program to get better, RS has to do what’s best for RS – not necessarily for us users. If the beta program isn’t doing what it’s supposed to be doing then it’s time to kill it and start over with testers that can do it right.
As you start to code all day, every day, you start to develop your own set of guidelines. I’d call them rules, but since I break them often enough I have to call them guidelines. Since I deal with my own code and Other Peoples Code (OPC) on a regular basis here are my guidelines (in no particular order):
- Name any control you reference in code. It needs to make sense to you. If you have a bunch of Pushbutton1, Pushbutton2, etc. pushbuttons you are causing yourself grief in the long run. You’re coding not only for right now, but for 5 years from now when you’re not intimately familiar with your UI and you want to make a change or fix a bug (or hand it off to a consultant).
- If you find yourself copy/pasting code over and over again you should think about a global method or perhaps a subclass. I’m talking about the MessageDialog alerts, the ComboBox helper code, etc. The reason this is a problem is that if you have the same code all over the place and you have to change it, you then have to change it everywhere. The chances of missing one hase big bug implications and your clients/customers may not appreciate the bug. This is called, by the way, refactoring and it’s not a bad thing to do.
- Big, huge, monolithic methods/functions are not good. My general rule is that if my method is over a screen length I start looking at ways to break it up into smaller chunks. This makes it easier to debug too since the runtime exception doesn’t have line numbers on where a bug occurred. All it can give you is what the error is and where it occurred (and even sometimes that’s not reliable).
- Name your variables something that make sense to you. You need to come up with your own guidelines, but the reason is the same as naming your controls. You should, at a glance have some level of understanding of what the variable is for. I don’t name loop variables (i, j, k, x, y, etc) unless I have nested loops. Some would argue that prefixing your variables is a dumb idea because RB is very strongly typecast and if you change the type you then have to change the prefix. Um…sure…that’s what global search and replace is for. But I can tell at a glance what type the variable is.
- Name your methods/functions something that make sense. Same reasons as above. If you can’t figure it out at a glance what it does, then you might need to rename it.
- One that keeps haunting me (in other words I haven’t always learned the lesson on this) is to use a thread whenever there’s a tight code loop. It always seems that during testing I have far less data than I will in real life so that tight loop that only takes a blink during development takes seconds in production and causes the app to ‘freeze’. Threads are a natural way to solve that problem. I urge you to not use refresh statements in your loops – instead use a thread. Of course threads aren’t perfect in that you then have to worry about how you update UI but if you have the Thread in the window you’re generally pretty safe.
- Test your cross-platform apps on each platform. Don’t assume that your Mac OS X application created in RB will look good on Windows and vice versa. Trust me on this one. Depending upon what you’re doing, Windows can be hugely different performance-wise than the Mac and Linux. Double-buffering is standard on Mac OS X and Linux but NOT on Windows so that really great looking custom control on Mac/Linux looks just awful on Windows because of flickering.
- Project organization is important. As your project gets bigger and more complicated having the big monolithic list of objects becomes harder to find things. I generally start with Application, BKS, Others, and Assets folders in my projects and put everything in those folders. The assets folder is icons and any other graphics for the projects. The application folder has all app object, all the windows and application specific objects. The BKS folder contains my own toolset of classes, subclasses, extensions, etc that I’ve written and use in most projects (I generally try to retain rights to any code in this folder). In the others folder is my toolset of objects that are from others and I don’t claim that I wrote. Some of these are encrypted and others are not. Keeping your project tidy is a good thing.
- Code first for functionality and once it’s working you can test for efficiency. I’ve found that some things I thought would be slow weren’t and some things I thought would be ok weren’t. Get it working first and THEN worry about it.
Those are mine off the top of my head. What guidelines would you share with someone new to coding and/or REALbasic?
