These are just some little tricks that I've picked up over the years. They don't do anything terribly useful. Instead, it's just handy "best practice" information. It's also stuff I've seen come up several times in recent memory.
1) Don't use Window.MenuBarVisible for anything. While it may sound neat and relevant, it's really only useful for kiosk applications and most people aren't making those. You see, it's a holdover from Mac Classic and its name sucks. It hides the menu bar (duh), but also hides all of the system UI such as a the dock and global floating windows. On Windows, this hides the menu bar, but also the task bar! So when that window is frontmost, BAM, your taskbar goes away. Oops. If you simply don't want a menu bar for a window, set Window.MenuBar to none in the properties list. Just as easy, and does only what's intended.
2) Speaking of menus, don't use MenuItem.Visible. It's generally considered a UI abomination to have menu item visibility toggling itself, which is what Visible is generally used for in other areas of the product. Instead, the menu item should be there and stay there right off the bat. The best way to do this is to make your menu bar have everything on it that you could possibly want, and when the window (or app, in the case of the Mac) opens, you simply use MenuItem.Remove to remove any unwanted items from the menu list. Since they're never supposed to come back, this works out very slick (it also gives you the chance to implement a menu handler for every possible item).
3) When working with control captions, use && instead of &. It's a UI and consistency thing. A & starts a keyboard mnemonic (underlined letter) in most controls, but you still need a way to show an ampersand. So you double it up. Even for controls which don't have mnemonics (like a PopupMenu). But, there's are two stupid exceptions to the rule: listboxes and comboboxes don't play nice. They don't convert && into &. Personally, I think that's a bug (don't have a feedback ID), but unfortunately, I'm not certain the behavior can change now without breaking code (it's a research item).
4) Implicit window instantiation is bad. Bad. BAD. Get in the habit of not using it. "Implicit instantiation" is the fancy name for saying SomeWindowName.Something. What that does is go "hmm, do I have an instance of SomeWindowName open? Nope? I'll make one!" And it leads to really weird and hard to track down bugs where windows suddenly pop open for no apparent reason. Instead, say dim w as new SomeWindowName This way you can control when and if that window is displayed. All the strange bugs just mysteriously go away.
5) Back to MenuItems... MenuItem arrays are bad. They're an ancient way of allowing you more control over what's on a menu, and they reek of age. Just use .Append and .Insert instead. You'll have more control over where things are placed, and it's a more logical approach. It also doesn't suck.
6) The debugger is your friend -- use it. I see a lot of people putting in MsgBoxes to tell them the state of a variable or something. This changes your application's state and can introduce other bugs. Just use the debugger! It can do the same thing, only it shows you tons more information and gives you more control to boot. If you have timing bugs, then use System.DebugLog. I can't stress this one enough -- if you're programming, you need to familiarize yourself with the IDE's debugger and use it because it will save you oodles of time.
I think that's enough tips for one day. I know there are plenty of other handy tips that I could discuss with you, but alas, I've got things to take care of this morning. I hope everyone has a fun weekend!
Yeah, on Windows, use System.DebugLog in conjunction with DebugView...it's very handy!
Hmm, have I offended thee? My comments used to always go through un-moderated before...I must be on the 'naughty' list now :(
@ #3--No, it's a feature request. ;-)
Sorry, couldn't resist! Haha.
@Corbin -- Your comments keep hitting moderation because your IP keeps changing. No worries, I always post everything anyways.
@Aaron, yeah, we keep getting power failures, so our IP changes often.
You still didn't elaborate on the 'SomeWindowName.Something' part. What do you mean, exactly?
I have to admit that I'm simply stunned at how many people don't seem to use the debugger or know how to use it and breakpoints
I'll admit that there have been some cases where I've had to use a DebugLog but they've been very few
@Corbin -- Let's say you have a window named Window1. Implicit instantiation is where you do something like this:
Window1.Show
You're implicitly making an instance of Window1, and it's always better to be explicit instead, by doing this:
dim w as new Window1
w.Show
I used to use the debugger all the time vers. 5.5 and before, however when the new debugger started making ZA go nuts (every change? really? ) even though the loopback adapter is allowed and trusted, I finally gave up on using the debugger at all.
@Bogs -- I'm sorry, but that one is entirely on ZoneAlarm. The debugger is doing absolutely nothing out of the ordinary. It's literally just binding to the loopback adapter, which has absolutely zero security implications for remote execution. I'm sorry that you find it annoying to use the REALbasic debugger, but you should contact ZoneAlarm about their bugs.
I think my previous post was probably not put as well as it could be, and this will probably also not be put as well as it could be. It was mostly a look at why (some)people wouldn't use the debugger, despite my knowing that wasn't what you meant when you stated #6.
For my hobbyish kind of programming, 5.5 pretty much was as good as it gets, with minor glitching. I *also* use 2006r3, which is where this behavior started making me decide not to use its debugger.
I realize using the loopback adapter is innocuous, as far as it goes. I further realize that it quite likely is a goof on ZA's side of the equation(at least in part).
However I have other programs that also use the loopback adapter and don't set ZA off, that change their state, etc., so it is kinda hard to square completely off on them alone.
Again, 5.5 never exhibited this kind of behavior, STILL doesn't, and so I keep using its debugger when trying to follow the flow of the programs I do write.
Using the loopback adapter to debug local,client side only apps is kinda hard for me to parse in any event, but then, if I were far enough along to understand the need, I'd probably be doing this for money bwahahaha :)
The fact that the compiler can spit out the .exe and stop at a bug kinda shows (me, anyways) that the loopback isn't an extreme necessary route, but again, there may be some huge bonus reason for needing to use it I'm just not clued into.
I guess the round-about-point I'm trying to reach is that I might believe you should be able to toggle that off/on as needed.
I admire your work, and have learned much from your site(and this blog), so again I hope this comes out better than it probably reads, and that you,um.....don't take this as either a knock on RB (which I like) or a personal knock on you (it isn't meant to be). It really is just an idiosyncracy for me.
***As an after note I didn't think to include in the previous post, as soon as I found this behavior it was reported to both RB and ZA.
RB at least responded, informing me this was the new way their debugger was going to go, they also suggested ZA should fix their scanner.
What I never found out was why it was a necessary way to go, and at this point in time its no longer a major concern (to me) some year or more later.
@bogs -- I think this might make for an interesting blog topic by itself... The reason why 5.5 doesn't exhibit the behavior is because that debugger was using shared memory (I believe), as were some other versions of REALbasic. However, that came with its own pitfalls and bugs, so we switched to using loopback adapters instead. Of course, named pipes instead of loopback adapters might make the problem go away as well, so it's possible we could work around it. As would implementing a "true" debugger, though that would take an extensive amount of work for incredibly little gain. All sorts of ideas -- but the loopback approach comes with the most benefit, by far (even when you factor in some of the crazy personal packet filters, like ZA).
Hmm... I may very well turn this into its own blog posting. :-P
[quote]Hmm... I may very well turn this into its own blog posting. :-P[/quote]
Well, I sure would be interested in hearing a TON more about this in a blog post. Would sure make for a long one (maybe 18 pages)if you were to cover all the whys and hows of debuggery (as it were)and all the possible ways to implement it :D
Oops, just realized what that lil blue thingie was . Nice breakdown though, thanks for the infor. At least I know whats going on now behind the green curtain.