QB Express: Issue #15

Letters

Letter From MystikShadows

Hi Pete,

*Picks up his Jaw and puts it back in it's place*

ASCII World made the Site Of the Month!? Wow Lurah and I were talking recently and making it to Site of the Month was what we wanted to do and look at that, it happened. Now we'll keep at it to see if we'll make it to site of the year and get Adigun's outstanding site of the year plaque ;-). It's quite an honor to have been chosen, and to see that if you put the effort, you will be rewarded :-). That surprise made my day and I know it made Lurah's day too. But I do have to say that the more recent activities were more caused by rattrapmax6's project, we've been busy, but so has he as you know, with his scrolling map maker and his other text projects. The Site of the month goes to him too :-). I'm honored to have him onboard our ASCII cult (err you can cut that part out if you want lol). Seriously though, from your description it looks like ASCII World is giving the exact impression that we're aiming for. That's awesome to know :-).

Just when the world (err the Qmunity realistically lol) thought this issue would fit on a single printed page so to speak, along comes you and the contributors and you guys manage to make a very surprising issue considering, like you said, it's state 2 days before the deadline date. Way to go people absolutely amazed every month at what makes it into every single issue. Even if it's as close a call as it was. It was all worth the wait and stress because just at the quality of the issue, absolutely impeccable. :-). The newsbriefs are still growing I see. [PLUG] For everyone, my offer still stands, if you want to make the news but don't have time to write about, send me the info, or just the link and I'll create the newsbrief for you, you don't need to waste time on that part and you can continue to spend your time on what you want to do, I'll take care of it ;-) [/PLUG]. srichard@adaworld.com is where you can send the info to. There's a lot going on in there. More and more things are becoming available for us FreeBASIC coders, it's absolutely amazing. It's always awesome to see it all happen.

The reviews were outstanding. All reviewers seems to have given a good, thorough and detailed review of their selected projects. I think I'm being selfish in my reviews ;-). When I say that, I mean i review stuff I like to play or like to use. So I tend to give them good scores I think. I'll have to try to be a bit more unbiased in them. But if you've seen rattrap's ASCII Map Maker 2.5, I think you'll agree it's an outstanding tool to use. :-).

I knew the Rogue Competition was busy. But I didn't know there could be so many types of rogue like games! Wow, I'm glad I won't be a judge in this competition. I vote if there's a poll of course, but wow, they have been busy, very busy.

I totally agree with Matt2Jone's letter. What he says is true, I've seen it myself, and I wonder how the victim feels in all this. Some really do deserve what they get, but others might be looking to really learn and I think there are better ways to keep their interest in programming than some of the stuff I've seen replied. If you don't want to help, don't flame them or send them to hell, let someone else answer, it should really be simple. I'm thinking something like. Imagine this: A new user that just heard of the praises of the Qmunity joins one of the forums, he gets flamed for whichever reason, another new member comes aboard and sees that he's been flamed, hence doesn't talk to him/her because he thinks they're trash, that's how you build or destroy an online reputation. Who's to say, this early those new member's presence in the forum, that they deserved this kind of reputation? As for myself, what I do when I see a new poster, even if he asks to do his homework is first start by seeing what it's all about. In this multicultural society of ours, I've had teachers I simply couldn't understand no matter how hard they tried to explain. Not all teachers are gifted in the area of teaching. Sure many of those new posters really do just want their homework done and be done with it, don't want to learn etc. etc. But I don't believe each and every one of them deserve the same treatment. So I PM them and see why they are asking us to do their homework. I've helped, in PM, many of those newbies for the reasons I gave in this paragraph. Many of them simply didn't understand the concepts that were required by the "homework" because the teacher either never explained it, never got to it or simply couldn't explain it simply. So I explained it to them and a lot of them were ready to do their work once I was done with them. If I see they are wasting my time, I just stop helping them. (those are the REAL nOObz :-) ). But I haven't been in this Qmunity as long as most (although I'm now nearing two years ;-)). Maybe some of you are burnt out from the nOObz lol. But I don't plan on changing my way.

Mennonite's "It's Been A Dark Month, Hasn't It?" really left a mark. Although I don't think it's been a dark month (looking at this issue, it hasn't been a bad month at all :-). However it doesn't take anything away from his positive thoughts he projects through his letter. Everyone should print this letter and read it (and reread it too) whenever they fell like giving up. It's one of the most motivational and powerful article/letters I've ever read. It says a lot about mennonite himself. Wish more people had that kind of thinking. :-).

I just can't help but enjoy Deleter's highly unique point of view in his articles. He's among the rare that can get a point across to the reader in a very realistic but also funny way. I'm looking very forward to others of his creations (hint, hint lol). He's just always a good read.

Matt2Jones' music series continues I see, that's just excellent. I'm a keyboard player and I really enjoy the way he explains music, it's proven quite informative to say the least. Torahteen really did a good job in this part of his "A* Implementation in FB: Part 2" he wanted to make a better, more professional tutorial, and I think he achieved that quite nicely. "C++ For The BASIC Programmer" by TheAwakened is pretty well done to. If you really want to use FreeBASIC to it's fullest, it won't hurt to learn at least a little C++ as many of the libraries/engines are coded in C++ so I definitely liked this one for those reasons. Ally Artificial Intelligence by John Wallace, what a perfect way to continue his AI series, when I read his first part, on enemy AI, I was wondering how he could follow that, ally A.I. never crossed my mind at the time, now that I read it though, I don't think he could have chosen a better subject for his second part.

In all parts, the issue was of exceptional quality once again, and I still see it going nowhere but up :-).

As always, I am going to reread this, see how much more I can sink into this brain of mine. Awesome work once again to everyone!

-MystikShadows (Stephane Richard)

In response to your thoughts on dealing with newbies, I agree with you: nobody should ever flame someone that asks a simple question. This is a small community, and we need as many members as we can get. However, I also think that people that ask questions have a certain responsibility to first try to answer their question on their own (by consulting tutorials, other forum posts and the QB help file), and then if they still need help, making sure that they answer their question in a thorough, intelligible way so that we know exactly what their problem is. When a newbie asks an unspecific or difficult to answer question, that's when they get flamed. I would say that it's way better to ignore questions of these sorts than to respond in a way that you know will not be helpful to anyone. (ie: "RTFM") Now, if you post the equivalent of "RTFM", and couple it with a link to a tutorial that will answer their question, that's a different story entirely. In general, I think that is the best way to deal with questions from newbies.

Great letter once again, from QB Express's #1 contributor! I'm sure I'll be hearing from you a few hours after I release this issue. :)

-Pete

Letter From Lachie Dazdarian

Pete,

I read in issue #12 your thanks to MystikShadows for his pre-formatting of his articles. First of all, I didn't know you could do that. I didn't know you could do that one article at a time. Shows my lack of HTML knowledge. You really should ask people to pre-format their articles if they want and can because I think most would do it. It gives them a chance to see how their article will look in the magazine and have more control over the formatting. I'm sure that most want to make editing QB Express less stressful for you (I know I do). Let's hope Adigun will read this. ;)

I will definitely do this in the future and thanks to MystikShadows' html files from the zipped issues of QB Express I know all I need to do the pre-formatting. Anyway, sorry I was unable to do this with my latest articles/reviews.

Another thing is your free time which will decline to "almost none at all" as you say in the issue #13. I know that I have no right to tell you how you should run your life but I was disappointed to read how you committed yourself on so many obligations which you really didn't have to. I would hope you would take editing QB Express more into consideration when allocating your free time since you express your love for the magazine so much. And believe me, by committing yourself to some of these obligations that are not "must do" you have allocated your free time to something other than QB Express. Also, I think that there is no need to force release dates so much. It's not like you have some publisher watching over you. I don't see what is so wrong in 40 or even 50 days passing between issues because of your limited time at that point. It's not a great thing but not something to break your head over. The community shouldn't thrive only because of QB Express. Actually it should be the opposite but we can't have that all the time. In the end, you don't owe anyone anything. I hope that you won't force issues so much and even release some few weeks after the last one just because the last one was a bit over the deadline. This really isn't necessary.

I see you have huge problems doing the news section and I'm really sorry I can't help there due my limited time on the net. What I think would help is some kind of News Box which everyone who has a site and updates it is advised to use it and post news in it. I think it would save you some time since you wouldn't have to check sites that have submitted news and would move responsibility of reporting news away from you and on to the newsmaker. Not only the site owners who update their sites should use it; everyone who thinks that he or she has something interesting to report could use it. Maybe that would lead to news inflation. I don't know. I'm not saying that this News Box should be a substitute for your or someone else(let's hope you'll find help) look-out for the news but it would save you some time.

I won't comment much on the last two issues but I should say that Adigun's work in the one year anniversary articles was excellent. I think his style is getting more coherent but it could just be me getting used to it. Whatever it is his articles are becoming a delight to read.

And thanks to both of you for mentioning my work so many times. My reviews are far from perfect especially in the grammar department and in my limited vocabulary but every new article is an opportunity to do better. I only realized with the last articles that I was using Simple Past Tense incorrectly. How embarrassing. And just few days ago I also realized that I'm using the word "graphic" incorrectly. This forces me to re-check my old articles and correct them. Since I'm a perfectionist I will open a website very soon with all my reviews corrected and the site design will be very similar to the one in QB Express.

I also want to apologize to everyone for reacting stupidly to your interview with Sumo Jo. After reading Na_th_an's letter, other comments, and the interview with Nekrophidius, I've got clearer picture of the situation and what was wrong with my comments. All I can say is that after the issue #12 I'm a bit smarter today (and I'm not talking about the tutorials). We never stop learning, eh?

What happened to the ASCII Summer Demo Compo? Well I know I won it (by default; one entry) but I'm surprised there was no news about it in the issue #12 since it was mentioned two times in previous issues(even an article about it in the issue #9). Lurah really did a poor job in managing the compo. We should all learn something from this. Don't start a compo when you are very busy. Anything else can be postponed but a compo can't.

What else...? Ah!

I've noticed many people having problems reading QB Express in Firefox. Isn't it possible to install more the one web browser on a PC? QB Express works great in Internet Explorer and maybe those people should download QB Express and read it offline in Internet Explorer, if they think that IE is so unsafe. I don't have a connection back home so it is a great pleasure to download QB Express at college and then read it home in IE, offline, in peace.

Anyway, I'm sending you a review of The Griffon Legend (how boring). I'm not sure if I'll be able to finish the next issue of Searching For The Unknown column for issue #15. This was a bit busy month for me which is partly my fault since I failed a certain exam and have to repeat it today. Also, I had to do this terribly annoying and draining medical testing for the military service for the third time (and it?s the last time, luckily). I was temporary unfit for the military two times before. I don?t know if any of you have been tested for the military but it's NOT the usual medical exam you have to do for driving the car or similar. It's comforting to know that I've gained 14 kg during the last year (it happened over few months) and now I have 63 kg(my height it 185 cm). Wohoo! I'm such a fat pig. Working out rules! The nurse who took my blood this time was unusually frisky. Ouch! The psychiatrist is another story. Hmm?does this interest anyone? Hardly.

Cheers!

Lachie D.

P.S. -- Does anyone know how to get rid of the Paint Shop Pro 7 registry files? They are driving me crazy! They keep giving me a message that I?have exceeded my trial period. Nothing helps. I went through the registries MANUALLY and removed everything that had something to do with PSP, re-installed it and it still didn't help. I never experienced something like this. Crazy! The crack sucks! (I don't want to hear any lectures about copyright) This leaves me currently without a 32-bit drawing program. Can you recommend something to a penniless person? Send help to lachie13@yahoo.com :P

Thanks for the great letter. Lots of awesome suggestions!

A few quick responses...

Thanks for pre-formatting. I'm not going to require it (since I think it might limit the number of submissions), but obviously I greatly prefer it since it saves a lot of time.

As for my free time situation, don't worry about it. I can manage a lot of things at once. QB Express is near and dear to my heart, but so are all of the other activities I'm involved in. Truth be told, programming and web design are an interest of mine, but they are not my passion. Television and cinema are what I want to do with my life, and what I am going to school to study. Most of my free time is spent making television shows for my college's TV station (which is also broadcast to the rest of our county). I am the creator/producer/director of a cartoon called "Unicorn Boy," the director of a live studio-based movie reviews show ("The Screening Room"), and the director of photography for a mockumentary show about student safety officer ("Better Safe Than"). Plus I am the webmaster of our official site, ictv.org . I love making TV. So I have all this, plus I take five classes and do all of the work / projects / studying, manage my QB site, my other Oh Cany Productions site, and do QB Express. But I can handle my commitments. I'm pretty good at time management.

Unfortunately, though, if something has to be pushed back, it's going to be QB Express. QB Express's release date is the one deadline that I have complete control over. Self-imposed deadlines are just too easy to break if you're in a bind, and I am regularly.

As for the news briefs, the only real way to do it is to search out the news by hand and write about it. In my experience, if I ask people to send in news to the magazine, they simply won't do it. I can set up all types of forms and infrastructure for news submissions, and only a handful of people will actually use it. So this won't work for covering all the news that I want to cover in the mag. Besides, the most interesting news stories are the more obscure ones that can only be found in individual forum posts, that the authors oftentimes wouldn't even consider "newsworthy."

Anyway, thanks for writing great reviews and always giving good feedback.

Take it easy.

-Pete

Another response from our proofreader, urger / Peter Lenz:

Lachie, don't worry about your English writing skills, I had to do little to get this article proofed. About your problem with PSP. You may wish to use GIMP. It's free, open source software (the best kind) and opens every image file format I've ever encountered. It may take some getting used to after PSP, but I feel the legality of it is more then worth the switch.

-Peter (urger)

Letter From Seb McClouth

Hi Pete

While reading the newsletter I�ve seen that people wrote regular letters. And today I thought to myselfs, let�s write one too.

First and all, I�d like to say what a joy it was to find an active community of Basic programmers.

I�ve been programming since I was about 9 years old, just real basic stuff. I believe it was actually my mom who taught me a bit. I had this keyboard, similair to an Commodore 64, which I could hook up to my tv.

I only knew how to use PRINT, FOR� NEXT, A$ =��, that about sums it up.

I thought it was sumfin really special (I still consider it is).

When I had my first real PC (about 10 years late), a huge laptop, a Toshiba 3200, I found qbasic in C:\DOS. Along with the PC I had a old STAR LC 200-colour (yes, with those old-and-fancy chainpaper) which I used to print out the complete help of qbasic.

I was writing some dumb programs which I thought off they were really cool. One of the coolest (which I didn�t find that dumb) was my ASCII-clone of Windows for Workgroups v3.x. I still have that code lying around. Now-a-days I laugh with it but when I wrote it, it was state of the art to me.

One year later we got connected to the internet at home and I browsed around looking for qbasic files. I downloaded lots of files, of pages which don�t exist anymore. In that time I was still programming ASCII-programs.

The graphical programming was not really my thing then. I found QuickBasic 4.5, like most of ya, somewhere. I downloaded, installed it on my 386 (yes, I know, in those days we had the first pentium up and running, I just didn�t have one myselfs) which was quite marvelous, it had about 16MB RAM, a 40 MB harddrive (later I added a 80 MB to install windows 95). About 2 years later I installed Linux Red Hat 5.1 on it. It was running a lot faster then windows did.

About 6 months later I got my first pentium. A Pentium I, 100Mhz with a 1 GB hardrive and about 64MB Ram. Running like train. So I thought. Well I had Linux installed once again and what a marvelous sight it was. Until I gotten a Pentium I, 166Mhz. It had about 92 MB Ram and a 3,4 GB Harddrive. Programming with QB had made place for programming with Visual Basic but I just wasn�t really happing.

3 years back I returned to Qbasic thanks to some old DOS-systems, currently a IBM Thinkpad, on old, which was capabile of running Windows 98, but anywayz� When browsing on the internet once more I found several Basic-communities. After a long while I found Petes site. After a couple of days I found this site to be really usefull in my attemp to create an OS (platform OS, as I call it, since it more sumfin like a shell).

Pete, keep up the good work.You�re running the best site I�ve ever seen on Basic.

On my behalf I wish you the best!!

Seb McClouth

Thanks for all the kind words! I can't wait for the next version of Qbinux!

-Pete

Letters from mennonite

I got several letters from mennonite in the past few days...

I hope you're alive

every day around this time i wait for the "qb express [#} is now available!" post on our subforum, and i haven't seen it. jesus, i hope you're okay.

actually, pete, i love qbe, but i've pretty much abandoned hope. i'm not suggesting you do the same, but i would understand. it's all good. as far as i'm concerned, no one other than you, mac, rel, and v1ctor contributes more to qbasic. you're the four horsemen of qb- imo.

but freebasic (for dos) has shown me things i can only see on my computer, and i love them too much to go back to only qb. and fb just kicks my ass around too much, like when i tried to learn c :( i'm very depressed. and i'm also depressed about everything else that's happening. and i thought, one more time, i'd share my thoughts on things... they're pessimistic, but i always hope the world will prove me wrong. i really do:

[ShadowWolf's post from the qbasic forum]

i disagree one thing Mac neglects to comprehend is that...there is no separation between QB and FB as a community and Qbasic.com has been the flagship page like it or not for the QB community. it is also the birth place of the QB community it tied together all the rouge pages for qbasic.

no a redesign of the Page must be true to the Community not the language it based around. Qbasic.com is this community father and Freebasic is part QB community it more then part of it, it is it there is no separation.

when FB was created QB community was dieing FB revitalized it and rebuilt it for me it was like watch a dieing person come back to life so naturally the majority of the QB community transition to FB so when you look at the FB community your really looking at the QB community. and to not representing FB with in the redesign of Qbasic.com you will be in essence alienating the largest component of the QB community.

i'm not advocating a convetion to FB but a blending simler to that of Pete's QB Site

Posted on Oct 29, 2005, 5:48 PM

[my reply]

you must not notice this is the last refuge for the newbies abused everywhere else in the "community." imo, the best argument for qbasic.com being seperate from the so called community is that here they are treated with kid-gloves. there have been exceptions. qbnz has a no RTFM policy but i've never seen much of qbnz.

on the other hand, after coding for two decades i am STILL one of the newbies who would have to take a lot of crap in other forums. i like petesqb- a lot- but there is a reason i spend most of my time here. pete berg has the best qbasic site there is- it's to qbasic what yahoo is to the internet. but mac has the best forum... for qb.

any excuse to keep this place separate (or even older-fashioned) from the "community" while i'm principally against it, may specifically be the only reason a REAL "community" remains at all. i used to think there was a qb community outside of this forum. but i think the term "clique" would probably apply better.

and if you insist on the term "community," why not be more accurate with: "anti-qb community" instead? like i was saying, mac's reasons for being protective might be misplaced... but he's probably doing the right thing anyway.

Posted on Oct 29, 2005, 6:23 PM

-mennonite

And then, mennonite sent me his scathing article about FreeBasic, which you should read in order to understand these next few emails.

Before I got a chance to respond to mennonite's first email and his article, I got this email.

You Don't Have To Run That

it figures doesnt it?

as soon as i sent that shadowwolf started helping me with fb.

i'm still unhappy. assuming you are alive and online :( you're probably WAAAAAAAAAY behind on qbe.

that's a pretty scathing article. i'm still annoyed, really. although i don't think the fbmunity (:P) deserves it.

it's almost a shame that i've ALREADY been proven "wrong" to a degree, although a lot of the sentiment remains. there is one point i think i'll stick to tho. even if you don't run it, it is probably going to be my last qbe article for a long, long time, at least. thanks again, pete.

And then just a few minutes later, I got this email:

nah yknow? i dont fuckin care- go ahead!

this is my last email.

fuck your whole stupid so-called "community."

fuck everybody in it. i don't care who you are.

some fucking cretin java programmer who claims you need OOP to spam a forum covered our forum in posts that said so today.

*I* can write a program that SHELL's to wget to spam our own forum. with phpBB it's harder, or there would be a program up right now that spams other forums.

using qb.

oop is a method, not an ability. any idiot knows that. you can code a while fucking oop langauge without oop.

i'm fucking fed up with people pretending to be part of something they deride.

i'm fucking sick of all the bullshit.

fuck the "qmunity" - a bunch of stupid children with nothing better to do - than the equivilent of high school boys running into the boys locker room in junior high and saying "hey look, our penises are 1/2 inch longer than yours."

whoo! there's a difference.

the lot can eat shit.

fuck 'em.

bye.

I don't think mennonite wanted me to publish these, but screw it. He hit a nerve with me, and I want to respond.

Publicly.

So here it is:

mennonite, I'm don't like your anti-FreeBasic attitude, and I disagree with you completely on the entire issue -- but I can live with that. What I can't stand are your constant jabs at the Qmunity for switching to FreeBasic.

Now this might come as a shocker to you, but: I don't like QBasic. I quit programming in QB in late 1999, and haven't looked back. I haven't programmed *anything* of my own in QB since. QB is so damn slow, limited and fickle. And now that the majority of the world is using Windows XP, I see no point in coding in QB, since chances are, my program won't even run for the majority of my userbase. Ever since I came to the revelation that I dislike programming in QB, I stopped using it.

So why do I run a QB programming site, make this magazine, post on message forums, etc.? It's not because I find QB programming particularly fun or engrossing. It all comes down to the community.

What I am interested in, and have always been interested in, is the spirit of QBasic programming. I love the idea of homebrew game programming, and I especially love the community surrounding it. To me, it's not the programming language or the technology that matters, but rather, the end products: the programs and games. QBasic is empowering to its users because it's so easy to learn, and it can result in some very fun, entertaining programs, that are itching to be shared among the community.

Your allegations that FB is unpolished, difficult to use, and missing features because it's still in beta, are unfounded. FB is what QB programmers have wanted ever since Windows 95 came out: a fast, expandable, multi-platform 32-bit compiler that keeps the formatting and simplicity of QBasic's syntax. There's nothing of significance that you *can* do in QB that you *can't* do in FreeBasic. FreeBasic + FBIDE is just as user-friendly as the QB IDE, and also (get this) works on my computer. QB and the many of the DOS-based programs it produces simply don't run on my Windows XP system. If every QB program in existence were converted to FB, I would be overjoyed. I hate jumping through hoops to get software to work properly. Nostalgia be damned. FreeBasic isn't QBasic, it's better.

The fact of the matter is that FB creates better end products, and that's why I support the switch: the programs are not DOS-based, and that means that I can actually run them on my Windows XP box. That's really all it comes down to. I want to use programs made by spirited amateurs of the Qmunity (whom I consider to be my friends). I could care less about the platform. If the Qmunity all of a sudden switched to Java programming but kept the same attitude, I wouldn't bat an eye. It's not like the past QB games are gone, and it's not like the face of the Qmunity has changed: we're still all the same guys. The platform is irrelevant.

And now for your other main argument...

You say that aside from the folks at The QBasic Forum, the rest of the Qmunity is uncooperative, cold, unreceptive of newbies, and "the equivilent of high school boys running into the boys locker room in junior high and saying 'hey look, our penises are 1/2 inch longer than yours.'" What the hell are you talking about? The people in the QB and FB programs are more than helpful to people, as long as they're not (a) asking stupid, vague questions that are impossible to answer; (b) making total assholes of themselves; or (c) asking us to do their homework for them. The FreeBasic.net, FBTK, Pete's QB Site and QBasic News forums are full of extremely helpful people and nearly everyone who asks a specific, intelligent question will be helped.

And what's wrong with RTFM responses? There's nothing that pisses me off more than people asking questions that I end up answering myself with a ten second Google search. Everyday someone comes onto my site's forum and asks a question where there has already been a full tutorial written on the subject that will tell them everything they need to know. Shouldn't we hold programmers responsible to at least check their resources before posting questions and wasting our time? I know that personally, I barely ever ask for programming help, because 99% of the time, I can find my answer by searching existing sources. Why do people have such a hard time reading the fucking manual? I don't blame the people that post "RTFM" or "Consult the QBasic Help file" or "Pete's QB Site has over 600 tutorials -- why didn't you look through those first?" Before anyone asks a question, they should at least make an effort to figure it out on their own. Most of the newbies that get berated are berated because they don't have basic netiquette.

Anyway, I'm not going to resort to swearing like you did to me and the Qmunity -- but I'll be blunt: you're wrong. The rest of the QB community has been pretty rational about FB, and only "The QBasic Forum" has flipped out about the new compiler. I consider you and your anti-FB cronies to be a fringe group that refuses to adapt to the changing world because you're too absorbed in tradition and "the old way." You're like the Amish: still living with no electricity and horses and buggies because it works. You're just too set in your ways. Computer technology has advanced past DOS, and it has gotten way better. You're the only person I know who thinks a DOS command line interface is more "user friendly" than Windows. And you're way too angry and defensive about the whole thing.

Not a single one of your reasons for not switching to FB works for me. Nobody It's clearly a better compiler than QB. And I think you're a major douchebag for ripping on the Qmunity like you did. I'm sure most of the readers would agree.

-Pete

Have a letter for the editor? Send all your rants, raves, ideas, comments and questions to pberg1@gmail.com.

News Briefs

News from all around the QB community, about the latest games, site updates, program releases and more!

QB Site News

QBasic.com Under New Management

After over six years of false alarms, eBay auctions to sell the domain, and failed squatting attempts, QBasic.com has finally changed hands. A guy named Mark Wilhelm was able to register the domain, and has since put up a barebones splash page that links to a new forum, the old forum at Network 54, and a mirror of the old QBasic.com site. In his announcement about his purchase of the domain, he asked the community for help in creating a new QBasic.com website.

The new QBasic.com logo.

As soon as the announcement was made, several debates began, the biggest about whether QBasic.com should also feature FreeBasic content, or should remain strictly QBasic-focused. Many believe that FB is simply the next version of FB, and that it's only natural for the site to be a blending of QB and FB, similar to what you see at QBasic News or Pete's QB Site. Others, such as V1ctor, advocated keeping the site with a QBasic focus, but linking to FreeBasic sites and providing some "education" to visitors that there was a modern 32-bit BASIC compiler.

Meanwhile, many of the visitors at the current QBasic.com forum, The QBasic Forum, got very defensive regarding the domain name, since their forum being linked to by QBasic.com is what has kept it alive and kicking for so long. If the link is removed, newbies will no longer flood the forum, and its visitation rate will drop through the floor.

Others met the switching of QBasic.com's ownership with hostility. When I found out about the switch, I wrote: "I really hope he makes a good site with that domain name. He's instantly going to get the most traffic of any QB site, be listed first in all of the search engines, and attract almost all the newbie QB coders...so if there's a bad site up there, it's a real shame. He's got a real responsibility to make QBasic.com something good, since it's such an important domain."

I wish Mark all the luck in the world -- but I am a bit worried about the fate of the new QBasic.com. Mark will be starting this site essentially from scratch, and hasn't really created any QB site of note to this point. So far, I extend him the benefit of the doubt, but I have seen nothing yet to indicate that he's got the credentials to manage this highly desirable domain.

News Brief by Pete

Lachie Dazdarian's Articles and Reviews Site

Lachie Dazarian recently created a website where he will be featuring his articles and reviews. As most of you readers know, Lachie has written reviews of games and has his own series on QB Express called "Searching for the Unknown". You can now find them on a new site create by Lachie specifically for the reviews and articles.

The site can be found here: http://www.kentauri.digitalblackie.com/articles/

The website features a design that is close to the know well known QB Express layout but under a different color palette which I find quite nice, easy enough on the eyes so that readers won't get a headache after reading the material. If you want to see his material, I encourage you to pay a visit to his website and get reading. There is some very interesting material already and I'm sure more to come as well.

News Brief by MystikShadows

QuickBASIC Gui Networks Opens

Chad Dweller, maker of Linster OS, a QB GUI project, just very recently opened a new QB GUI related website. There were only two, so he decided he would be the third. It's all new so there isn't much content GUI wise. He does have his own GUI there however and the organization of the website seems great navigation wise, let's hope that with time he will get enough contributions from people to be considered a good QB GUI reference. The URL for his website is http://www.linster.moved.in/qbgui/guppy/ Take a look, it's well on its way :-).

News Brief by MystikShadows

"Enter" Section from 3-2-1 Contact Magazine

The '80s and early '90s educational kid's magazine 3-2-1 Contact is back! (kinda). There are 111 scans of "Basic Training" articles from 3-2-1 Contact magazine available at the following link, courtesy of Michael Birken. I'll be adding this to the QB Zines section eventually. (WARNING: *HUGE* file...don't download unless you really want it): 321contact.zip

Here's some info from Mike about the scans:

Pete,
The "Enter section" in 3-2-1 Contact magazine evolved from Enter magazine. If you never heard of it, check out this link:
http://en.wikipedia.org/wiki/Enter_%28magazine%29

Over time, the Enter section got smaller and smaller and soon only "Basic Training" remained. And then that disappeared completely. There were some really cool programs in there some times. I couldn't find the issue, but there was once a variation of Lunar Lander. The game required you to get a flying saucer through a jagged cave by only tapping on the space bar. Each tap initiated your rocket booster to momentarily fight gravity.

You should make a call out for more scans. It would rock if we could locate all the issues of Enter magazine itself.

- Mike

Shortly, this archive will be added to the Pete's QB Site "Zines" section.

News Brief by Pete

Two Generous Offers from Todd Suess

For those of you that might not know Todd Suess, just take a look at his website at Todd's QB GUI Review website and you might remember that it received the site of the month award on QB Express #12. Todd is a very active member of the QB GUI scene with his review website, his own GUI project called Millenium OS and all the help and suggestions he gives to anyone thinking or working on their own GUI projects.

After exchanging a few Private Messages, he let me know that he had just created a forum specifically designed for people wanting a forum for their GUI projects but that didn't want to create their own website and/or forums just for the sake of their project. Todd create Data Components Forums. Basically, if you are thinking of creating a GUI project for yourselves, if you have a project and would like a forum dedicated to bringing you your own section for your project so you don't have to host a forum yourselves and if you're curious about current GUI development projects, you must visit Todd's forum.

Todd also added that he has created another concept to offer free webhosting to anyone who needs it. Have a look at Metronic Hosing (BETA) which offers 15Megs of free webspace to anyone that signs up. 15 megs is good enough for alot of endeavours so go right ahead and take advantage of his generous offer.

News Brief by MystikShadows

A New Preview of the QuickBasic Game Directory

Lachie Dazarian is at it again. In a post he made in the QBasicNews forums, he announced that he is creating a QBasic Game Directory. You can currently find many titles already added to the database (321 titles at the time of this newsbrief).

The preview website is right here: http://www.kentauri.digitalblackie.com/qgdpreview/

Be sure to take a look at it so you can see where this project is going. In my opinion, this layout will really help to quickly locate our favorite titles quickly and easily. Likewise, if some sort of search facility was added (as I'm sure Lachie probably already has in mind to add), it would make finding our games even easier.

Note that the website is a preview only and not all aspects of it work, however, it looks more than a promising new resource for everyone to enjoy. So, if you want the latest and greatest of the QB Gaming experience, be sure to keep your eye on this "soon to come" excellent resource.

News Brief by MystikShadows

Grand Opening of "QBWiki" by Torahteen

Torahteen, a self-described "fourteen year old on a mission," announced the opening of a brand new QBasic/QuickBasic wiki (user-edited online encyclopedia) at the beginning of October. The site, simply entiteld QBWiki, "is pretty much completly void of any articles," so Torahteen encourages us: "so start writing. If anything, just write a few crappy defenitions. It'll start growing... soon... I hope."

Unfortunately, it appears that this QBWiki didn't really catch on; in its first three days of existence, there were several updates, but they died off. There hasn't been an update since October 5th. Perhaps the Qmunity feels that the current QBasicNews wiki is enough, or that we already have enough online resources for QB programming. Oh well.

News Brief by Pete

Syn9's Hideout Gets Major Revamp

Syn9, the guy behind The Griffon Legend, Vampira and Zero G, did a major revamp to his website this month. Now, Syn9's Hideout has a much cleaner, more intuitive design, and more extensive information about Syn9's other past projects and demos. Most recently, Syn9 has posted new screenshots of the ships from his upcoming 3D racing game Zero G Academy -- and they look absolutely spectacular. If you haven't played through Syn9's phenomenal games yet, you absolutely have to visit this site!

News Brief by Pete

ASCII-World launches the ASCII World Software Development Initiative.

ASCII World has created an initiative to help find and keep Text and ASCII projects, applications, tools, utilities, games and library available as well as a unified means of making software available to the rest of the internet world. the ASCII World S.D.I. (Software Development Initiative) is an effort to accomplish the following things:

Find all types of Text and ASCII programs already created so they that do not dissapear off the face of the internet. Project owners will be contacted as we find them, to see how ASCII World can make them available to it's visitors.
Create Text and ASCII programs in any category and programming languages to attempt to fill in the game of missing useful programs and games available as Text and ASCII programs.
To offer a unified label for program makers (all software categories) as a symbol of the S.D.I. effort.
To create and manage a global catalog of the available text and ASCII programs and games to quickly locate the programs of interest, get information on them, who to contact, and other related information for the visitor's convenience.

Just another way that ASCII-World is showing its dedication to Text and ASCII based software development.

News Brief by MystikShadows

Project News

Poxie Gets an Update

After reading about Poxie, Lachie's latest creation, you'll be happy to learn that Lachie has been busy creating an update for his game. Those of you that played Poxie since QB Express #14 might have noticed an issue about the game taking up 100% of the CPU usage while it was executing. I'm happy to announce that Lachie has fixed this problem now.

Make sure you get the latest version of Poxie, version 1.1, from his website: http://kentauri.digitalblackie.com/

This way you'll be sure you don't suffer the 100% CPU usage blues and can feel the full experience of this interesting and entertaining game. In Lachie's own words it was a small but very important issue that he can now put in the past.

News Brief by MystikShadows

Phat Games Rerelease Kids of Karendow

Blair of the Phat Kids has completed an updated version of their QB classic Kids of Karendow. This first version is only a re-release of the original with remixed music, which will eventually be followed by Karendow Revisited, a FreeBasic adaptation of the original KOK.

If you've never had a chance to play Kids of Karendow, this is the perfect time to give it a spin. This long, challenging and hilarious RPG will keep you enthralled for hours.

It can be downloaded at this link: Karendow.zip

News Brief by Pete

Dkl's GUI Creator

dkl, a user from the FreeBasic.net forum, has created a tool that could very well change the way we create windows applications in Freebasic. He calls his project GC (Gui Creator) and it is plan to support Windows only. GC will use the Windows API to create the windows and dialogs. Check out these two screenshots right here. The aim is for it to be as as close as possible to the Visual Basic form designing tool, and as you can see, it's well underway.

As you can see from these screenshots, GC features a uniquely designed interface that yet seems to be on its way to being very functional. Just click the button to add a form and voila, the form is there ready to be manipulated, with the controls needed by the user. It also features some very nice icons for the toolbar that clearly identify what the buttons do.

I think dkl all the collaboration he can use in this project as it really is very promising and if it does get finished, we will all benifit from his (and our) work. You can follow the development of this project on this thread http://www.freebasic.net/forum/viewtopic.php?t=1491 on the freebasic forum.

News Brief by MystikShadows

Fun500 GUI

Here's a short article that Brandon Cornell wrote about his upcoming GUI, Fun500:

Intro:

I'm 12 and the Programmer of Fun500 GUI. This is my first Article for online posting. Its about time I posted in this great QBasic magazine. I have been on the online QBasic community for over 6 months now.

The start of Fun500 GUI:

About a year ago I found X-GUI 3 and Jacobpalm.dk But I had no clue how to program gfx. Easter 05 I read a graphics Tutorial and in hours I had made Fun500 GUI 2005.

Fun500 GUI Now:

Fun500 GUI now has moveable, closeable,and minimizable windows(50 at a time),buttons(150 at as time), text boxes(100 at a time), and up to 15 lines of text in every Window. (Data from Version .25/.20)

I plan to soon add a desktop, but cant add a script because I an going to use a UniScript.

I also Hope to make a Word program using the font for Fun500 GUI 1.0 that will be used in more than just my GUI because It sounds like a hard task.

Web Site:

My Web site is: http://fun500.us.tt.
We are hosted by Metronic (Todd Suess)

Brandon Cornell

News Brief by Brandon Cornell

VonGodric Releases New Version of FBIDE

By now I don't need to introduce VonGodric or his awesome project that is FBIDE the el facto of FreeBasic IDEs for Windows. VonGodric just announced the official release of FBIDE version 0.4.3. As he mentionned in his release post on the many forums we all visit, it has been a while since any new version of FBIDE were released, however, if you take a look at the changelog, wow, was it ever worth the wait. Here is a copy of this changelog.

Version 0.4.3
* Added Compilation now takes place through FPP extender ( Eric Cowles )
* Added several help file shortcut's into help menu ( vongodric )
* Added Context help via wiki. ( vongodric )
* Added Status text of compilation progress into statusbar and tittlebar( vongodric )
* Fixed bug with opening illegal tab. ( F9 ) ( vongodric )
* Fixed fbide now tries to detect FBC on it's own -before asking the user ( vongodric )
* Fixed seperators in toolbar ( vongodric )
* Fixed several syntax highlighting errors ( vongodric )
* Fixed FBIde no longer empties it's clipboard apon exit ( vongodric )
* Changed FBIde is now compiled with wxWidgets 2.6.2 ( vongodric )
* Changed New indent mopdule -faster, smarter. ( vongodric )
* Changed Console area is now resizeable using splitters ( vongodric )
* Changed '$ - is now recognised as preprocessor statament ( vongodric )
* Changed Cleaned up keywords, added missing ones ( vongodric )
* Changed New nicer looking about dialog ( vongodric )
* Changed Single mouse click in SFBrowser will go to selected S/F ( vongodric )

As you can see, many issues have been taken care of in this release, some more important than others, but all this contributes to the ongoing success of FBIDE. With this and what is on the workload for future versions of FBIDE, it's sure to make this Integrated Development Environment even more popular.

News Brief by MystikShadows

Adigun Azikiwe Polack AFLIB2 Progress Report

I'm sure today, most of you know of the existed of Adigun's AFLIB2 project. He's been quite busy working hard on his project to bring you all the functionality you'd expect from the fact that AFLIB2 is based on AFLIB1 release for QB over 3 years ago and the RelLib library as well. For those of you that didn't hear about the AFLIB2 project, take a look at this thread started by Adigun himself right here: Adigun's AFLIB2 announcement thread on the FreeBasic.net forum as well as here: His QBasicNews Thread started on the QBasicNews forums to get more details.

This is an ongoing project of Adigun's. So, I decided to create a monthly status report bringing you the most up to date information on the development status of AFLIB2 based on the information I get from Adigun himself. I won't introduce the first AFLIB library nor will I talk about the RelLib library as I do not believe they need any introductions today. However, so far, from what I've been told by Adigun, there is alot of surprises in store for AFLIB2 that will make it well worthy of it's new version number.

Aside the many demos and screenshots that Adigun has been creating and showing on the threads mentionned above among other places, he has been keeping me updated on the status of everything. As you know from those threads, adigun has been working on integrating a Scale2X and Scale4X system to AFLIB2, i'm happy to report that the Scale2X phase of integration is now completed and is working quite well. If you want to know more about exactly what Scale2X and Scale4X are, have a look at the Scale2X project on sourceforge. Adigun mentionned that after Scale4X is done, he will be creating complete working examples of Scale2X and Scale4X to allow us to learn (the fast way) how to effectively use these features.

From what Adigun told me, the overall AFLIB2 project is about 48% completed and is advancing well and fast. He's currently working on finishing the Scale4X implementation and his next steps after that are horizontal and vertical scan lines. No doubt that he knows where he's going with this project and seems to have it all layed out and ready to code. Judging from the first AFLIB project and the RelLib's popularity, I think AFLIB2 is sure to become one of the most widely used library available out there for FreeBasic.

As a last minute bit of news, Adigun has mentionned that he now recently added Scale8X to AFLIB2's arsenal. Which gives even better effects to graphics without the need for antialiasing or other forms of image smoothing and edge hiding techniques. Adigun created a demo of this technique that you can get from his thread on FreeBasic.net Forum AFLIB2 thread and he even created some translucency-based fades in the demo, he's looking for some feedback on FPS rates (Frames Per Second) with and without VSync inabled. If you could run the demo and tell him your FPS numbers on that thread so he can evaluate the performances on various CPU configurations I'm sure he would appreciated it greatly.

News Brief by MystikShadows

Competition News

Roguelike Compo Update - October 15th, 2005

As most of you know from QB Express #14, There has been a Rogue like compo on FreeBasic.tk. Every month I will be bring you an update on how things are going. A progress report of what's done and what's left to be done so you can get an idea of where each team stands in their projects. I went to their forum and simply asked the teams to give me a short status report and have collected the replies right here for you: (There may be more participants, but these are the people that replied to my inquiry).

NOTE: For screenshots of what each project looks like, you can have a look at the QB Express #14: Gallery section to get a glimpse of what their respective projects. Also, you can go to my status report thread FBTK Roguelike Compo thread to see all the replies.

rdc (a one man team) mentions: "[Deep Deadly Dungeons] is about 98% done. I am tweaking the gameplay, doing code cleanup and working on documentation.". From what has been said, rdc is the closest to finishing his game.

Dr_Davenstein said: "Zap is on vacation, so our progress is only about 10%. We would have been alot further by now, but I really wanted to do one in 3D, so we started over from scratch in the middle of the competiion. I've got the basics of the engine done. Right now, I'm working out the menu and battle system. I'll update the demo when you can kill stuff." Thank God there's no deadline if you look at the screenshots (link above) you'll see that deciding to go the 3D way was an awesome idea.

Jocke The Beast: "My project has now become a more of a team-project then anything else. Adrew Collins (the main coder of the engine) has been away for some time and I don't know weither I should wait for him or try myself to continue finishing the roguelike. And to be honest, I've been so impressed by Rick Clark's work that my focus has more been to watch his progress then my own Cool Well, let's see...Anyways, things to do for me & Andrew are: Magic effects, attack effects, balance combat, monster special attacks, save & load function, clean up item-code etc."

marzec: "working on the core engine which is approx. at 60% now. got to reimplement multitexturing and blending in the core as this was just a hack to see how stuff will perform best. what's still waiting to be implemented is a proper renderqueue and a more genric mesh and material class. also pending are the animator and animatorstatus classes that will controll an objects animationstatus. implementation of subclasses of class partitioning, which will establish spacial partitions so collision detection and frustum culling gets more performance. what's also missing are proper 3d shape classes and intersection routines. as this is a simple matter of copying and pasting code from somewhere else it shouldn't take to long. The net library is more or less done, the only thing that is missing here is the bridge between the lowlevel net library classes and the actual game engine. The sfx library is still in design phase, but as it is very similar to the gfx library just a little simpler it shouldn't be that time consuming ( maybe 3-4 days, fmod is rather nice ). Input classes are done of course hehe...Working on uml diagramms to nail down the complete design of the engine beforehand ( well at least uml sketches :p ), finding new things i didn't think of before. the engine is also going to be used in an rts game so i want it to be as generic as possible ( gfx, sfx, net and input that is ). will take some time :p " Looks like marzec has opted for the prepared approach with the UML (Unified Modeling Language) modeling.

And there you have it, 4 teams have replied to my question and I truely appreaciate the time they took in keeping me (and you readers) up to date. See you next month as I bring you more of the latest and greatest of this ongoing Roguelike Compo.

News Brief by MystikShadows

Other News

New FreeBasic IRC Channel

I've just been informed of the existence of an IRC channel that's been created for FreeBasic not too many people there but if we look at the number of people that are using Freebasic right now I think the channel has alot of room for improvement. You can basically talk about anything there, a cool place to hang out. But you can also get immediate help if you have specific questions.

The irc server you need to log into is irc.freenodes.org and the channel is #freebasic. At the time of the writing there was 8 people on the channel so it's not exactly dead...but definitaly has room to grow. I'd like to personally invite you to give this channel a try.

News Brief by MystikShadows

The GamerPlusPlus.com Introduction to FreeBasic

Jason Bales (a.k.a. Delta-G) is hard at work at a new tutorial / "book" on programming in FreeBasic, and it's coming along nicely. Here's the message I got from him...enjoy!

I am writing a short book on FreeBASIC programming. The direct PDF download is at: FBbook.pdf

I also have a plain HTML export (it still needs to be gussied up) at: FBbook.html
I'm not too far into this project, but some of your site visitors may be interested.

-Jason

News Brief by Pete

Nekrophidius and Rhiannon Welcome Baby Rhianna!

On October 29th, Basic Network founders Nekrophidius and Rhiannon gave birth to their first child, named Rhianna Arecelis. She's a beautiful baby girl, weighing 6 pounds and 7 ounces. Congratulations Nek and Rhia! Everyone at QB Express wishes you all the luck in the world, and we know you'll be great parents!

News Brief by Pete

Send your QB/FB news to pberg1@gmail.com!

Game Production

Written by Matt2Jones

Author�s Note: Production as in the way music is produced, not as in the actual game development.

Pete needs more articles, and I don't have the final music one done yet, so I'm going to rant on about easy effects you can put in to games to make them appear extremely professional. Basically I'm going to be talking about the styles and fashions of computer games...

So, First Up -

Logos

When you go to see a film the Logos of the various studios and companies involved are put their (Aside from advertising reasons) as a showcase of the power behind the film your watching, to sort of intimidate you into thinking 'Jesus, these guys are Gods'. The most important part of a Logo is for it to seem all powerful and unstoppable, Universal use the globe that revolves, Dolby have the flying through space effect, etc.

In a Game the same principle applies, but their application is slightly different. In my mind the most impressive way a logo can be displayed is without delay (i.e. No changing screenmodes just before or afterwards), just a straight palette fade in, a two, two and a half second pause, and a fade out again... Waiting for a keypress can be detrimental, as it gives the user some control over how the logo is displayed, and the whole point behind them is to impress upon the user your all powerfulness. I also recommend a relatively slow fade in and out, as it gives the impression of a monumental force, slowly, but inescapably, thundering towards you, and away. Fast fade in/outs suggest it's extremely lightweight as is being fucked around by the force behind it...

Let me explain that a little clearer. Big things with a lot of force driving them move slower then small things moving with the same force, so if you see a big thing moving really fast, you think there's something wrong about it, and it must be lighter then it looks. Imagine rolling a 50kg rock down a hill, it slowly building up speed, decimates everything in its path, and then slowly decelerates, coming to a halt long after the hill has ended. Then imagine a sculpted styrofoam ball made to like a rock. It will reach its maximum speed going down the hill about as soon as you push it, it will bounce down and stop almost instantly at the bottom... Not a great show of an unstoppable force.

As far as the actual logo design goes, if you're fading from black stick with mostly dark colours, and stay away from smooth colour fades in the picture (But any pixel artist can tell you that), it looks unprofessional, and comically compared to it's dramatic introduction.

Sound effects for the Logos are surprisingly unnecessary in games (given their prevalence in cinematic logos), and I'd advise staying the fuck away from them unless it takes NO TIME AT ALL to load and play the sound, any stalls before or after the dramatic showing cheapen the effect, and make it look like your game can't actually handle the resources it's showing itself off with (which is not a good thing). Also try an avoid audible speaker clicks as they are turned on and off, as anything that may clue the user in to how your doing what you're doing helps them understand what's going on in the computer, and people don't fear what they understand (generally speaking)...

The most important thing is the Logo has set the mood and pace of the game that is to follow; anything that comes afterwards that doesn't fit in with the rhythm it provided will bring your towering powerhouse crashing down.

Title Screen:

Obviously a Title screen should be designed to be looked at for a long time. All I can really say about them is the following:

If the title screen is a menu system (i.e. expecting some sort of complex user input) it's perfectly acceptable to have a still bitmap in the background (make sure it's of the same quality, or better, then the logo's that proceeded it however), or even a solid colour, or fading screen, but if it's more of an arcade style title screen (just a 'press start to begin play'), then under no circumstances put up something that simple, or it will start to feel (from the user's point of view) like an un-impressive logo, that they have control over. In an arcade style title screen you NEED some sort of eye-candy, or it falls to pieces.

Run of the mill techniques would be to have parts of the picture fly in from off screen (not as in the picture is cut up, and squares fly in, but each sprite, or word, or letter), multiparalex style scrolling effects (bands of sprites scrolling across the screen at different speeds), or simple flame animation/blinking eyes/smiling mouths/wagging fingers/blowing trees/etc. I'd shy away from massive full-scale animations because the title screen should probably be able to loop indefinitely, and it's much better not to go back through the intro again (shows the user how you�re doing things), so multiparalex scrolling, small areas of 2 frame animation around the screen that can be kept on repeat are best.

As far as music goes, it's probably advisable to introduce the main theme of the soundtrack here (the theme song if you will), so the players begin to recognize it, and it will have significance when it appears in the game again.

The Game

The main message here is that abused 90's buzzword 'multimedia'. The secondary message is speed uber alles.

The NSDP pun:

I've heard it said that the guy who designed Quake said (and I paraphrase) 'any amount of graphical fuck-ups will be gladly overlooked as long as there is really fast action and gameplay.' He's an eloquent bastard, he is... Anyway, it's fucking true, most people complain endlessly about the FF games turn based fight system, because it's slow and boring, where as they all rip each other to pieces to piss a little closer to the almighty Zelda games (despite the fact everything else about them is shit), because they are fast. How this equates to FB/QB is not quite as dramatic... Just don't ever use inkey$ to take keyboard input, use a multikeypress system (like MULTIKEY for example)... It's unbelievable how much it adds to your gameplay (If you actually look at the increase-in-enjoyment factor, you'll find it's less of an addition, and more of an exponential increase)... Frustrating controller response has brought down consoles before, don't think your game will fair any better.

Basically, if you feel your game is lacking, speeding everything up is a industry tested catch-all solution to the problem (even if it makes it unplayable, anything hyper-active automatically gets a cult following, see Excel Saga and Puni Puni Poemi...). There is a very real and imminent reason why Sonic and Mario had a 'speed the main character up' power-up.

The gay-ass industry jargon:

Humans are visually orientated. Even deaf people can get by okay because they can see; it's a lot harder for a blind person to get the same from life using their hearing only. This means use lots of colours, this means have fuck loads of movement (just vibrate the sprites around their locations if they aren't doing anything), and stimulate the player like they�re an ADHD toddler. It's not just having good graphics, but it's manipulating them well. Evangellion, one of the greatest anime ever, got by not with state of the art animation, but beautiful image manipulation. Multiparalex style effects are unbelievably easy to manage, and really look good. Slow panning/zooming over a large picture instead of holding it still on the screen is a stupidly easy-to-implement mood-builder. Flipping between two/three frames repeatedly can often be just as good as running a mini animation, and infinitely better then (or maybe just twice or three times as good as) a still picture that flashes up.

Following on with the ADHD toddler analogy... Has anyone hear ever seen Japanese television advertisements? Model you game on those. They. Are. In. Sane. Every screen action can be easily accompanied by a .5 second wav sound-effect, and this sort of sensory bombardment is proven to hold the attention of anyone playing your game. The sound effects don't have to be good, they just have to be their. Would anyone describe advertising jingles as good pieces of music? No. How many of you would sing the chicken tonight song if I started? ~50%. And that is all I need to have a majority (to the pedantic among you, (50% + 1) = a majority).

None of these suggestions tell you how to make a good game, or code better, then are just suggestions on how to make a game look sleek and 'professional' without having to change your coding style... It's like the difference between a song recorded on a single track, or with 14 drum tracks, 3 vocals, 3 backing vocals and 34 guitar tracks. It doesn't mean the song is good or bad, but it means the radio and MTV will play it.

Author's Note: for the record, the games I deduced this checklist from were Sonic The Hedgehog 1 and Mysterious Song. I don't know why, they were just the images in my head at the time.

Matt2jones
Email: Matt2jones@yahoo.com

Review of The Griffon Legend by syn9

Written by Lachie Dazdarian

Yes, yet another review of The Griffon Legend. You must be thinking now something in the line of "Does The World Need Another Review Of The Griffon Legend?". But bare with me. Why it should be odd that some game gets reviewed more than 1 or 2 times? Think about all the movies that have been reviewed over 1000 times. Now when we think about the size of our community 3-4 reviews of one game shouldn't be something strange especially if we are talking about an excellent game as The Griffon Legend is. Anyway, I really want to run this game through the "VPlanet grinder".

For those who don't know(really?) The Griffon Legend is an excellent action RPG of a smaller size with excellent graphics and great music. The best FreeBASIC game released so far(September, 2005).

Graphics

The Griffon Legend's graphics are a strange mixture of very detailed and excellent sprites and tiles and few surprisingly poor and/or poorly composed tiles. I was mostly impressed with the style and the skill displayed by syn9 having in mind that this was his first serious 2D project. What I especially liked were the graphics outside the castles(trees, grass, etc.) and, what you can't see from the screenshots, the animations in sprites. The movement of the main character and other "small" enemy characters is very skillfully and realistically animated, as well as the attack animations. The Griffon Legend also features chain-like animations with the boss enemies which are very cool but this feature alone wouldn't mean much if the graphics that make it, and the rest of it in general, weren't excellent. It's important to mention that The Griffon Legend doesn't feature any death animations. When you kill an enemy it simply disappears. I didn't really miss this feature much except with the boss enemies but when it comes to scoring the graphics I have to take this into consideration. The place where this "flaw" is most obvious is in the moment when you kill the end boss. There is no a single moment between the last blow you inflict on the end boss and the outro. The same thing happens when you die. The program simply kicks you back to main menu. The menu graphics and the design of the game submenu is, however, flawless. The main menu and the screens outside the castles feature a very cool fog effect which shows the benefits of using 32-bit graphics so well. I should say that the number of different tiles in the game is relatively small but works for a game of this size. One thing I really didn't like relates to the foreground layer. On most places where foreground tiles are used if you walk into a foreground tile from the side and slightly below it part of your character's body will end being covered by it while the bottom of his body won't because the tile under that is a part of the same wall or pillar belongs to the background layer. A similar thing happens with the status bars placed below the main character(as well as with the ones below the enemy characters). All this really ruins the illusion which foreground tiles suppose to create.

The game's screen resolution is 320*240 and it's nice to know that there are programmers still interested to work in such resolutions. I'm not alone! Anyway, if the game featured death animations and some "ugly" tiles didn't happen The Griffon Legend would get 5 in this section very easily despite the doubtful foreground layer. The graphics in this game might be better than in some other games which I scored with 4 too but those games featured a more coherent and balanced style. Syn9 shows so much skill and ability that the presence of these flaws puzzles me.

⁴/₅

Sound/Music

This section was missed in the Josiah Tobin's review and that was the main reason for me to do this review. Why? The Griffon Legend features brilliant music. Maybe a bit too strong word but I don't know how else to describe it. Since I own a PC with a sound card for a quite short time I can't say I'm much of an expert in this department. But comparing The Griffon Legend with all the other games featuring digital music I've played so far it's music is right in the top with the music from Star Control 2. Anyway, maybe it's not so smart to compare music from different games. What's important is that the music in The Griffon Legend fits the gameplay like a glove and highly enhances the play experience. Right from the menu music(more of a humming) you'll sense the high quality. During the game 4 music tracks exchange except with the boss battles where a special boss track accompanies it. While they are all excellent I should point out "Spiders In The Willow Trees" and "Dreaming Awake"(intro and the outro music) as true gems. David Turner, the guy behind the music, is obviously talented. Anyone who has him making the music for his or her game is blessed.

The sound effects are very good but I can't say excellent. None of them seems out of place but you kinda feel there should be more of them. Some blood squish, hurt, foot-step, distant humming or breathing sounds would be cool. Just try to play the game without the music and you'll know what I'm talking about. Also, one sound effect is incorrectly used. Every time you change a scene you hear a door opening sound while a door is not between all the locations. A bit silly mistake. Anyway, if you were not able to play the game with the music your are missing the BEST aspect of this game beside gameplay.

⁵/₅

Gameplay

The gameplay is rather straightforward and entirely based on action with some simplified but notable RPG elements. The Griffon Legend doesn't feature scrolling which means the game world is consisted of single-screen rooms. You can avoid most of the enemies in this game but it is imperative that you kill as many of them possible in order to level up and on some screens to receive a key which is necessary to unlock certain doors in the game. Every time you revisit a location the enemies are revived(doesn't apply on bosses, of course). From time to time you will have to beat an boss enemy which always leaves something behind crucial for the progress in the game. It's interesting to point out that some enemies that are a boss in the first part of the game are nothing but regular enemies later in the game.

Placed below your character are three bars representing health, attack and magic. When you attack an enemy(you character attacks by leaping forward and flipping with his blade out) your attack meter completely depletes and then slowly recharges. The strength of you attack depends on the attack meter. The way spells are used it very similar to this. Later in the game when you beat the first boss you will receive a crystal and by using this crystal you can and should find 4 spells: spinning blade, ice whirl, falling rocks and fire. The spells are used by accessing the submenu(press CTRL) and aiming them toward one of the enemies. The game pauses during this procedure. Each spell has it's own "energy" meter and after using a spell it's meter also completely depletes and you can't use that spell until it recharges to full. Also, every time you use a spell the main character's spell meter depletes and if you use another spell before it recharges to full that spell will be less powerful. By killing enemies you gain experience points and when you accumulate enough of them you level up. By leveling up your attack and shield strength increase as well as the speed of attack/magic meter recharging and your maximum hit points. Spread all around the game are flasks which recharge your health and there are two better shields, swords and armors to find. But the best shield, armor and sword is protected by a secret boss which kinda looks silly (bat-cat?) and I was only able to kill it by cheating (it was really difficult). It really doesn't pay off to beat it.

The game features enough different enemies and bosses with different attack features/patterns to make this game very entertaining to play and not boring above all. While the battles require more than mindless sword swinging they are in the same time very simple and not frustrating. The spells add a lot to the gameplay in the sense of strategy and making better results in crowded battles. It is very obvious that this game was heavily tested and it paid off. While in some battles, especially with the bosses, we can spot the flaws in the gameplay it's enough excellent to get a perfect score. Requiring more would be unreasonable. A note: You can use the "rock" spell to destroy some of the obstacles in the game(red spikes). This reminds me. The Griffon Legend could really use a better documentation.

⁵/₅

Story

The story is somewhat original but not very deep. In a nutshell it's about griffons versus dragons and you play the role of a Griffon Knight. I guess it's more original than humans versus evil [insert race name]. The story is well written despite the few mistakes I've noticed but nothing more than that. The story is presented in a form of passing text placed on the orange foggy sky both in the intro and the outro. No cinematics. This game probably doesn't need more but giving The Griffon Legend a higher score in this section wouldn't be fair to game developers who put a lot of time and effort in the story and story development.

³/₅

Replay value

My least favorite section in the VPlanet's reviewing system. A very difficult section to score and often not terribly relevant. As with most RPGs it's always interested to give the game one more spin after you finish it applying the experience gathered from before but you will probably be more motivated to re-explore the game world using a save game position where you are near the battle with the end boss. Playing the game all over, with a so weak character, I didn't find very appealing. This game simply didn't do it for me in the sense of "playing it over and over". If the game had some bloodbath/practice mode where you would play for score with a time limit or something similar that would be another thing.

²/₅

Challenge

Not a very difficult game but most freeware RPGs aren't. Of course, being an action game too The Griffon Legend requires more than patience which is not the case in great deal of freeware RPGs featuring turn-based battles. There will be quite few screens in the game where you will be victorious only after several tries and leveling up is required to be successful as the game progresses. This game feels more difficult than it really is. The way majority of the boss battles failed to play interesting(especially with the end boss) is another reason for this score.

³/₅

Fun factor

The Griffon Legend really excels in being fun and entertaining and despite all the flaws I've mentioned it succeeds in emulating a professional design and leaves you with good memories of it. Yes, it's not the longest game out there but I think this shows in the total score. If you haven't played The Griffon Legend yet SHAME ON YOU!

⁵/₅

Total Score

²⁷/₃₅
Good: Excellent gameplay and graphics. Great music.
Bad: Relatively short game(around 2 hours of play time). Few flaws that could have been easily avoided.

Visit http://syn9.thingie.net to download The Griffon Legend.

Graphical User Interfaces - A Complete Study
Part 1 - GUI Design

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

When I wrote Graphical User Interface - Design Concepts back in issue #13 of QB Express, I was wondering if and how I could continue this series, or what more I could write about in the field of GUI development. Brandon (from Jacob Palm's website ) recently emailed me the answer to that question he said: "Could you maybe write a Tutorial series for QB Express on how to make a GUI?" and that clicked. Although it's not a complete continuation of the Design Concepts, this series will be based on the design concepts I mentioned in that article.

In this first part of the series, we will start from the beginning, ask the important questions and see what we can come up with. Of course, your GUI project will have different answers to some or all of these questions since a GUI is really a question of taste, your personal taste and the taste of your potential user base. You will learn however, what these questions are and how to answer them specifically enough to have some valid information to work with when you start the design of your GUI. So let's get down to it. There's a lot to cover so I'll do my best to be as clear and concise as I can be.

WHERE DOES IT ALL START:

That's always the hard part it seems. Usually, if you have the idea to create a GUI it's typically because you saw a GUI that you either really liked or really hated. If you liked it, you'd like to make your own that works the same. If you didn't like it, you'd like to make a GUI that works the way you want it to work. If it's neither of these answers, then you just might have gotten inspired by the fact that GUI development itself, no matter what the language, is a hot topic and you want to be part of it. The truth of the matter is that GUI development is, in itself, a great way to learn to program. It's a big enough project (even the smallest and simplest of GUIs) so that it covers a lot of programming grounds. When you programmed a GUI you have a good understanding of many programming fields and if you develop enough tools and applications for your GUI, it will just broaden your programming knowledge. But the most important reason to take on such a project, is for the fun of it. If there's no fun, there's no point and that should go for any and all personal programming projects you'll ever give yourself.

in my letter to the editor in QB Express #12, I shared my reasons why I thought GUI development was such a hot topic in the Qmunity. I don't know how many agree with me, but those are also my reasons for wanting to create my own GUI. All this to say that you start by wanting to create a GUI. If you want to create a GUI then it shouldn't be a problem to actually make one. What comes next? Let's find out.

HOW TO BEGIN THE GUI DESIGN:

Jacob Palm wrote an interesting article on what a GUI should have in QB Express #10 so this section is not about repeating what's been mentioned in this article. How to begin a GUI is really about sitting down, determining the basics of your GUI and then seeing if you're on the right track. To me, there's two main reasons to create a GUI. The first reason is because you'd typically want to use the GUI you're making. The second reason is usually because you want others to use it. It's great if these are the your two main reasons, especially if they are in that order. If you're making a GUI just for others to use it, it won't be as motivating. However, you'll need to both to put yourself on the right track and keep yourself on the right track through the development of your GUI. Here are some very typical questions you might want to ask yourself at this stage of the project. Right now, I'll enumerate the questions and later in this first part, I'll answer the questions and how these answers apply to my own GUI project. Hopefully this will help you answer these questions yourselves for your own GUI projects and see how these answers can affect the different parts of your GUI.

How will the GUI look?
Since it is a Graphical User Interface, the visual aspect of the GUI is indeed, very important. There are many parts to a GUI and each of them should like like it belongs with the rest of the GUI elements. How it looks is entirely up to you but if you want users to use your GUI, making a poll, asking around are great ways to help make sure that your GUI is on par with what the potential users might want to see. Here you can ask yourself such things as: Do you want it to look and work like Windows�, Mac OS�, Amiga Workbench�, or whichever other popular GUI you're thinking about. How similar you want it to be to that GUI, how different, and so on. Just really sit down and decide on exactly what the user can expect when they startup your GUI. Is it a 2D or 3D based GUI is another good question to ask yourself at this stage. IF you can, maybe you can even use a drawing program (I use paintbrush, it's enough for me) and start drawing some visual sketches of your idea, see what works and what doesn't but in a very broad sense, nothing too specific, just enough to give you a good idea.
How will the GUI work?
Believe it or not, this questions, although somewhat related to how the GUI looks, really has nothing to do with looks. Basically, at this stage you're not thinking about Graphical representation. You're thinking about "inner workings" or the beginning of the inner workings. This is where you'd answer questions like what can the GUI do, how would it do it. Can it get input from the keyboard, mouse, joystick, etc? Can it print? can it open and save files? So as you can see this question has nothing to do with looks. You can also decide on if the user will need to double click to get something to happen or if a single click will be enough, and what standard keyboard shortcuts you'll want to use (more on this later).
What programming language will I use to make this?
This is a very important factor which is why I put this 3rd in this list of questions. The other two questions following this can definitely be affected by which language you decide to use for your GUI project. There are, as you know, many languages that you can choose from. And if you're passionate enough about your GUI project, learning a language you didn't know before to make sure your GUI is good would only broaden your knowledge horizon even further. Therefore you need to look at what you want to make, what you want to include in your GUI project, and then, looking at the programming languages, see if any of them might be better suited for the task.
What special features/services will the GUI Have?
As you know, windows isn't popular because it's simple to use or looks good (although special efforts were put into making it look good). It's popular because of everything it offers. Such as, networking, Internet access, Direct X, Open G.L., Open A.L. and everything that is considered today some of the hottest features a GUI should have. So it's good, for the sake of your GUI, to take into consideration at least some of these hot features and see what and how you can offer them as part of your GUI. GUI development should be about a balanced combination of these features combined with a great look and feel. Depending on the goal of your GUI, you might not even need any of these hot features, however, I think they should be seriously considered at the very beginning of your project. If not for anything else, knowing you'll want to include some of these or not can affect the way you code, you might leave your code open to new additions where you might not have if you didn't take these into consideration.
What Operating System the GUI run under?
Someone said that making a GUI for Windows� really didn't have a purpose. To that I say that if you are planning to sell your GUI, I agree with that statement 95%. However, if you are creating a GUI for your own use, maybe the use of a few friends, making a GUI for Windows� makes just as much sense as any other operating system, it again depends on the real goals of your GUI and why you are making it. But even commercially, some GUIs were available for Windows�, take the Norton Desktop which came out back in the days if Windows 3.XX. It had a certain degree of success and was indeed a GUI for Windows�. Also Central Point Software created Central Point Desktop which also made it's way. This is just to say that who knows, making a GUI for Windows� might not be all that bad of an idea.

Some of these questions require a bit more detail when you answer them of course. But once you've sat down and answer them the best you can (take an extra day or two, or a week if you need to) you'll be much better prepared for the rest of the project. When making a GUI be it a very simple one, or a very complex one, it really helps to sit down and answer these questions to begin with. This will form the guidelines for the rest of the project. And now, let's see what I answered for my GUI project ErgonOS.

MY OWN ANSWERS TO THESE QUESTIONS:

When I first decided to make a GUI I had no idea what it would look like or anything. The only thing I had on my mind at the time was "I want to make a GUI that's simply never been seen before!". With that thought in mind, I started seeing what was out there. I visited Jacob Palm's website, found out about Todd's GUI Review website and started seeing what was already created , what they offered, how they worked, how they looked and the likes. I did this because I didn't want to make anything that already existed. This lead me to thinking, what if, I used something different on which to base the whole GUI on. What if the GUI wasn't defined by the applications it had but rather by some other form of defining attribute. With this in mind, here are my answers to those five questions. I'll put them in the order I answered them because in my case, how it worked governed all the other aspects of the GUI including how it looked. Here goes:

How will the GUI work?
I started telling myself: " what do I do when I use Windows�?". Typically I don't just open Windows� and look at it. I'll either manage my files, write a document, create a spreadsheet (always love playing with numbers), create a webpage, program, browse the web, get and answer emails, play a game and chat. Then it clicked in my mind that Windows� wouldn't be Windows� without the possibility of doing all these things I do in Windows�. This is when the idea of basing my GUI totally on the document saw the light of day. In other other words, it wasn't all about the GUI itself, it was about what the user would do with the GUI. Once I had that concept in my mind I opened up Paintbrush and started creating a GUI based on the files themselves and not the applications that used these files. Ideas started connecting together with this model. For instance, I wanted a quick way to find the files since they are first priority. Likewise, as a programmer, I wanted to hav a quick way to locate files that had any relation to the file I was working on currently. For example, if I was coding maybe related files would be other source files in the same directory, todo lists, and other files that have to do with that given project. Same thing if I'm designing a website, maybe I'll want the other html or php files that pertain to the current website. Maybe I'll want images I used to create buttons and other visual aspects of the website. I think the best one phrase comparison I could use to explain my concept is this: Windows Mac OS/X Linux all use the Desktop metaphor where you have the screen (the desktop) and on that desktop you have what you'd need placed somewhere on your desk. ErgonOS uses the "Workload" metaphor where you have your list of things you want to work on or do and the GUI adapts itself to give you the functionality, features and tools you need to perform the work you are undertaking.
How will the GUI look?
How the GUI looked in my mind was based on how it worked. This meant that the document would have the majority of the screen real estate but directly visible would be means of relating and finding files that I would typically need to work with the current file. As such, an image formed in my head. Quickly, I opened up Paintbrush and started putting that image in my head into Paintbrush to see how I could all make it fit together. One small thing I added (since I love command based applications like dbase and forth programming) was I wanted a command area where I could type commands to get things executed or files opened, whatever I wanted to do. One of the goal of ErgonOS is to allow to do anything from the command prompt that you could do with keyboard shortcuts and mouse clicks. in other words if it exists in the GUI it can be accessed from the command prompt. Here's a screenshot of that design: (some of you might remember this from Jacob's GUI news featured in QB Express #12).

Note that this design's original size is 800x600 which is the minimum resolution I wanted for it. At that scale, the design concurs with the items I detailed in my "Graphical User Interface - Design Concepts" that I posted here. At 800x600 (if you set your screen to that resolution), the buttons are quite big enough, even the scrollbar buttons to be easily and quickly accessible with the mouse. In my opinion, ErgonOS is very well designed for the target resolution and will offer a very efficient usability factor. The Project related items are files that pertain directly to the currently active file. The related Items could be other files of the same type, or anything you think can be useful if quickly available when working on your current file. The search Engine section is of course to search your Hard drive directly. The Shortcuts (bottom right) will probably be called Tools since that's basically what it will contain, things like a calculator, and other popup tools that you might need while you're working on your current file. It will have the ability to change on a per file type basis so you can really customize each type of file with the tools that really relate to that file. Each tab (upper right main section) represent a given file, more than one file of more than one type can be opened at the same time. All sections of the GUI can be resized and/or hidden except from the main section so that you can organize things the way you like them.
What programming language will I use to make this?
This is were I broke the "common knowledge and reasoning" factor. Go all around the web and ask the classic question "I want to make a GUI, what language should I use?". the "very big" majority of people will tell you, use C++, some might tell you to use Pascal or ObjectPascal, some might tell you to do it all in Assembler even. But I chose to do it in FreeBasic because it's a new language and since I want to do this for DOS and FreeBasic can create 32Bit DOS applications, I figured it could do the job quite well considering it's many DOS related features. I also chose FreeBasic to show the world how good it really is. Now if you think QuickBasic or FreeBasic or any basic is incapable of making anything close to a GUI. think again. Go to Jacob Palm's website or Todd's GUI review website (who's links are mentioned above), every single GUI reviewed on these sites were made with QuickBasic. So it just might be more capable than some of you might think. And since FreeBasic can do DOS 32bits with ease, it was easy for me to choose it for my project.
What special features/services will the GUI Have?
Other than the features I want to incorporate as far as usability is concerned. I will also be researching what is out there and what I can "possibly" make to allow for network support, Internet support, soundcard support and USB ports as far as hardware is concerned. As far as software is concerned, although the GUI won't make use of any special features (to keep it lightweight and efficient) I will want to use the Allegro game programming library. I will also research to see what other graphical library there exists and if it can be supported in ErgonOS. As well, to make it even more usable, I will be crating an SQL based 64 bit Database system. I will also see what DOS based database systems exist and see about integrating them to ErgonOS. Using something based on the principle of resource files, I want to implement multilingual features in the GUI so that users can define their own language for the OS to use. Finally, I want this GUI to be fully programmable in it's own compilable scripting language.
What Operating System the GUI run under?
In the case of ErgonOS, I decided to create for MS-DOS and variants like DR-DOS, PC-DOS, FreeDOS, FreeDOS 32 and other MS-DOS based Operating Systems. The main reason is because DOS is what I grew up with and still today I use it. Another good reason I chose DOS is because I'm also thinking of creating my own drivers for the operating system (in a phase 2 or 3 of the project). So I don't want any conflicts with existing drivers and I want this GUI to run on the most basic of system provided it has enough RAM and good enough video card to operate at 800x600 resolution. Because it will be a 32 bit Application, It will need at least a 386 to be able to work. Once these DOS based OS are done, I might see what I can do implement it for the Linux Operating System. Whether you create your GUI for DOS, Linux, Windows, or anything else, it's important to make sure your GUI can execute the native OS functionality. Since I'm making ErgonOS for DOS, it will have the ability to run any DOS programs at least in fullscreen mode. I'll see about creating a DOS window or something, but that will come at a later time. At least to begin with, it will be able to run the programs.

Because of all the OSes I want to be able to run under, I will have to do my best, in the coding process, to make sure I isolate (and eliminate if I can) anything that can be OS Dependant at a very low level. This is commonly known as creating a level of abstraction between the GUI and the operating System. This way, any code that absolutely must be OS Dependant can be in a specific place and easily changeable and maintainable for the other OS I plan to support. This goes for any other ErgonOS related projects such as the database system and whatever else I'll be thinking of in the process. The GUI will come with it's own set of basic GUI tools and utilities like a file manager, calculator, graphics program, text editor, and other basic GUI related software. it will have a control panel that will allow the user to change most aspects of the GUI as well.

THE QUESTIONS ARE ANSWERED, NOW WHAT:

As you can see, I think I have a pretty clear picture of what I want my GUI to do and how I want it to do it. The design phase doesn't stop here however. Sure you can start coding, seeing how and if a few things work, basic research and development..but official coding for the GUI shouldn't begin right away (especially if your project is as big as a GUI). The most important defining attribute of a GUI is to make the computer easier to use as compared to it's non GUI counterpart. In that respect, you need to sit down (again) and start thinking about how simple your GUI should be based on keyboard, mouse and joystick considerations among other things. A prime example of this was Word Perfect 5.1 for DOS. It had every feature you could think of and more for a word processing application. So many in fact that it had no choice but to put some of these features in very complex key combinations like "Shift+Control+Alt+Key" that became very hard to learn and remember. So you need to sit down and think about a few factors. When you design a GUI, if you want it to be simple to use and easy to learn, You'll have to take the time to create standards, even more so if you're making your GUI for others to use.

If you use an Open Folder as an Icon for your File/Open options, you'll want to use that same icon for any program that allows to open a file regardless of what it does with the file. If you use the F2 key to Open a file, you'll want to make sure that any program uses F2 to open a file. This makes your GUI and any related programs that much quicker to learn and get used to. Which key you use is up to you, the important thing is that you use the same keys for the same functionality thought your GUI and that goes the same for which icon you use in your menues and/or toolbars. Also, a GUI is not just an environment to run other programs or games in, it is a user oriented interface to the DOS commands and instructions and show, therefore, offer standard things like file and folder management. With this in mind, here's a little table explaining the keys I decided to use as a standard.

ErgonOS Standard Keyboard Definition
Key	Description
F1 Help	F1 will bring the ErgonOS help system to the screen, if the User presses Shift and F1 a context sensitive help will be brought forward.
F2 Open	As you might have guessed, I selected F2 for the standard File Open operations. Anywhere you are in the GUI working on whichever type of file, F2 will always allow you to open a file.
F3 New	When you want to create a new document or file, pressing F3 will always do that job for you. The current document (if any) will determine the type of the newly created document. If you have no documents or files opened then a list will be available to select the type of document you want to create.
F4 Close	When you're done with a document or file F4 will close it for you, if it's changed it will ask you if you want to save it first. CTRL and F4 will close all files of a project that are open (a quicker way to close all project related files).
F5 Goto	Since the age of Lotus 123 for DOS, F5 has been accepted for the means to get to a certain place in a document or file (in this case a spreadsheet). So I kept that standard for ErgonOS.
F6 Search	This is pretty self explanatory. If you want to find something in your document or file, hit F6 and a standard Search/Replace dialog will appear asking you for standard search related information. If you already had a search, F6 will search again for the next occurrence of your criteria
F7 Print	Do you want to make a hardcopy of your current file, F7 is the key to press. Shift F7 will bring the printer parameters dialog up. In other words, F7 and it's Shift, CTRL and Alt combination will all be about printers and printing for any document type.
F8 File Search	This is what you press if you don't have the file open but know what you're looking for. Specific file related criteria will be asked for so you can find exactly the file you want.
F9 Options	If you want to change any aspect of working with a given document type. For example colors, available tools and the likes, F9 will allow you to do just that.
F10 Menu	As you might have guessed, I selected F2 for the standard File Open operations. Anywhere you are in the GUI working on whichever type of file, F2 will always allow you to open a file.
F11 Custom	I want to leave F11 and F12 definable by the user. However, by default F11 will bring the standard file manager up for operations. That will be true for any file type unless otherwise specified by the user.
F12 Custom	User definable as well. It's default will be the ErgonOS global control panel and options dialog. That will also be true for any file type unless otherwise specified by the user.

As you can see, taking the time to write these down like this, I won't forget them for one thing, and it really help give a purpose to the GUI. I think it's very reassuring to know that no matter where I am and what I am doing in the GUI the same keys will server the same purpose. How quick and easy to learn does that get? To me, that's really what a GUI is all about easy to learn and use. Added to that a good visual design, and you have yourself a winning GUI combination. Taking the time to create such seemingly insignificant things as keyboard standards just helps add a stabilizing effect on your design. This was standards for the keyboard. The same can be done for the mouse (button graphics and all).

Another effect that creating these standards to is give you a better idea of what size your project will be. For instance, F1 will bring a help application up this help system will need basic functionality to open and search a help file and other help related operations, F2 will require us to create some standard File dialogs that allow us to browse the folders and file to select one (or more) file to be opened), this adds to our list of things to do and help us create a very tightly integrated GUI environment. Later in this first part I will enumerate these different GUI additions and describe them. I will of course need to design those dialogs so I can show them to you later in this series when we really start to code the GUI part itself. But in this first part, you will at least know what those dialogs will be.

The more alert of your might also have noticed a pattern in my keyboard key definitions. Just Pressing the key affects the currently opened file, Shift and CTRL and Alt Affect the current file type. This is to say that the keys that are the more quickly accessed will have a direct relation to the current file. while the combination of Shift, CTRL and Alt will broaden the reach to a wider set of related files. This is my way of optimizing the functionality. Of course you can create your own standard as well, just be very specific as to what you have in mind it will make the standard easier to follow for all others that will use your GUI. In the next section, we'll break the the GUI into it's basic elements and enumerate them so we know what we'll have to code for in the following parts of this series.

BREAKING DOWN THE GUI ELEMENTS:

if you take a good look at the screenshot above, it represents the finished and combined GUI. However, this is not in a usable state. To make it usable, we have to take each component of this GUI independently and save them in different filenames. Some of these we'll have to break into sections even because of the fact that they will need to adjust to different heights and widths depending on the size other controls are when the user changes them to his or her taste. As you can see there are 6 main areas on the screenshots. Let's review them and detail the purpose of each of them.

The Main Area: (Upper right section)
This is where most of the action takes place. Each tab represent a complete document. Selecting the tab brings that document upfront so that the user can do what he needs to do with it. You can notice the menu on the top which works as a standard pulldown menu system. Under the menu is a toolbar (which could grow to 2 rows if needed to provide shortcuts to commonly used functionality for the given document type. If the file is a document, the menus and toolbars will change to give the user options typical of a word processing application. If the file is a source file, again venues and options expected for editing, compilation and execution will be presented. If it's a drawing they will provide drawing related options. This is what i mean when I say the document will govern everything that the user can do. Now if you're running a game that needs to work in fullscreen mode (for whichever reason) or a specific application that needs the full screen, the main area can be zoomed in and/or maximized to accommodate that game or program.
The Command Area: (Right under the main area)
I am a DOS or Console lover. The command area is where you can enter commands and have them executed. You can also create batch commands that will be read and executed line by line. You'll be able to copy files, create folders, open files for editing right from the command prompt. The command prompt will be designed to allow all GUI functionality to be used at the command level. This means that you could even automate what files get opened as well as even change the width and colors of different elements of the GUI right from the command prompt. For those that don't want the command prompt you can hide it and gain more realestate for the main area.
The Shortcuts Area: (Right under the command area)
This area is where related tools and utilities can be assigned for a given document type. Let's say for example that you are working on a document. You might want to go into the paint utility to make a drawing for your document, you might need to calculator to get some results for a report you're writing. Well you can decide to put these two tools in the Shortcuts bar for quicker access to related tools and applications. Items on the left of the shortcuts are related tools, I Items on the right could be even more user tools or things like the file manager, control panel for the document type and other global GUI components. One of the main goal of this GUI is to allow itself to be totally customizable to the users taste and way of working.
The Project Related Area: (Upper left section)
Projects typically are used to group files together. If you're programming, you just might have more than one module for the current project you're working on. If you're creating a website, more than one html or php file, if you're working on a document, it might have more than one file. If that's the case and whatever your current document does relate to other documents, you can just take them all and drag them to the project related items box. Whenever you open the project you'll have access to all other files instantly. They don't have to be of the same file type either. In a website you can easily have html, jpg, png, gif files that all related to the current website you're building. they can be grouped just the same.
The Related Items Area: (Middle left section)
To better explain this one. Let's assume you have a folder, in that folder you have 20 source modules, some resource file (*.rc), some graphics, documents for your analysis of the programming project, and a couple other files (configuration or project files for example). let's say that the 20 source modules are already part of a project. You load that project up and you can see those 20 files in the Project Related Area. The Related Items will show all the other files in that folder that are not in the project you just loaded. This GUI being a document based environment, having access to pertinent document or files while working on other files will be it's main specialty and the Related Items is just another means of making files easily and quickly available to the user. This section can be resized to give more room to other areas of the GUI. It could even be completely hidden if the user doesn't want to see them at all.
The Search Engine Area: (Bottom section)
How many times have you ever told yourself: "Wish I could remember in which file did I put something or where did I save that document to?" the search engine is there to answer that very questions. Again because ErgonOS is file based, a readily available search engine is a very logical option to have. it will search your whole system or the current folder or the parent folder for either the file, or the contents of the files for what you are looking for. That section too can be hidden as well. Many user might prefer to have more screen realestate for the related items and the project related items and simply click on the file manager tool if the need to find other files. Again it's really up to the user to define how he or she prefers to work with the GUI.

These six zones represent the whole screenshot that you see above. as I mentioned early, most of these can be resized and even hidden to give more space for the other areas. How it looks is entirely up to you. You could even put the main area on the left if you wanted to. It really depends how you like ErgonOS to work for you. Of course, the whole GUI doesn't stop at these 6 areas however. There will be a good list of tools (such as the calculator and file manager) that will appear as popups on top of the GUI. The next section will describe these tools (I will list the basic tools that "should" come with any respectable GUIs for my taste (but it's up to you and your GUI project to decide what you want as "essential" tools.

ERGONOS TOOLS AND UTILITIES:

I've already mentioned a few previously in this document. But as you know, a GUI is only as usable as the tools that are available. There's quite a few tools I plan on adding, I will enumerate them here with a description. Later in the series I'll create screenshots of those to give you an idea of what they will look like. I'm listing them here so that I don't forget them later in the development. These tools and utilities will just help make ErgonOS even more usable. Note that the main area will already have the ability to edit plain text files (this includes any source files, html file, notes, and so on. It will also allow to edit Rich Text documents and I'm thinking of making a small but quite useful spreadsheet application too. Added to that are these following tools:

The File Manager:
Essentially, this will be much like the Windows� file manager application. On the left you'll have drives and folders, on the right you'll be able to see the files that are in that current location. You'll be able to move and copy files from one location to another and perform other standard file management tasks.
The Calculator:
Pretty much self explanatory. However this calculator will come in 4 flavors. Regular, scientific, programmer's calculator and financial. With these 4 calculators, there isn't much you wont be able to calculate. To me at least, the programmer's calculator and the financial calculator are really missing from standard GUIs. If you think that GUIs like Windows� are for home and business use, these kind of tools should be included.
The Image Editor:
What's to say about an image editor? It will allow you to open bitmaps and other types of image files, work on them or create new ones, save them and anything else you might want to do with your images and photos. One feature I will add to this is the ability to manage photo albums and be able to categorize your pictures.
The Home Financial:
This will be a very basic but useful system where you'll be able to do such things as: your personal budget, home inventory, mortgage calculations and amortization tables, saving up for college or other projects. Useful tools for people wanting to plan their life a bit ahead of time.
The P.I.M. (Personal Information Manager):
This is a self contained application that will allow to manage your contacts, appointments, personal notes, some databases, to do lists, birthdays and the likes. Think of it as your electronic organizer. Basically, I want this GUI to be useful even if you just install the GUI itself. And by providing tools like this one and the others, you help make sure that people will be able to accomplish some basic useful things with your GUI.
The Control Panels:
Each file type will have it's own control panel. A standard dialog will be provided to allow the user to configure these file types. The main reason for this is, for example, each sourcefiles can then be configured to be compiled from different compilers for example. It will also let you define which shortcuts/tools you want available when you are editing files of that particular type. as well as decide the size and location of the six areas of the main GUI. There is the global GUI configuration where you can decided on the colors to use as well as the global settings for the six areas of the GUI.
The ErgonOS Scripting language:
Just to clear things up a bit, this is not the batch file interpreter, or at least it's not just the batch file interpreter. The purpose of the scripting language is to allow you to create your own applications and tools that you feel you need. It will of course have a very BASIC feel to it so it can be learned quickly. And will allow access to all parts of the GUI and inner functionalities.

These tools and utilities are the basis of what a home computer should be able to do. Never mind a GUI or not, you buy a home computer it should be able to help you at least manage your home. it's the one thing I always hated is when you buy a computer for your home only to find out you can't do a thing with it unless you get something else. That's basically why I want to create this set of tools, to really make the home computer useful.

ERGONOS STANDARD DIALOGS:

As I mentioned above, this section is where I will describe all of the standard dialogs I will need in this GUI. Standard dialogs are elements that any program can use to perform their operation. They are dialogs that make available standard functionality typical of a GUI's functionality. Let's list them here again so we don't forget about them and also, to give us a more complete view of the coding we'll need to do for the project. There are basically 5 dialogs, here they are:

The File Dialog:
This dialog is called up when you need to open or save a document. Basically it presents the user with a list of clickable drives and folders and when a folder is clicked the right side of the dialog reflects the files that are in the currently selected folder. The user can then select the file(s) he or she wants to open or enter a name of a file if they are saving a file to disk. Once they are done they can hit the Ok or Save button (depending on the file operation they were doing) and the action will be performed then they will be returned to the main GUI. Pressing the escape key or clicking on the cancel button will exit the dialog without selecting any font.
The Font Dialog:
ErgonOS will use different fonts, these fonts will be available to the rest of the GUI and file types as well. A standard means of selecting the desired font is therefore necessary. This dialog will present the user with a list of available fonts, a preview area so they can see what the font looks like. The user can then select the desired font and click Ok to select the font and go back to the main GUI. Pressing the escape key or clicking on the cancel button will exit the dialog without selecting any font.
The Color Dialog:
Depending on the screen resolution and pixel depth currently selected for the GUI, this dialog will offer different color options. These colors can be used when writing documents or files or when drawing pictures. The dialog will present a bitmap of colors (based on the pixel depth) as well as Red, Green and Blue values that can be edited directly. Choosing the color on the bitmap will also change the values of the Red, Green and Blue textboxes. Clicking Ok will select the color and go back to the main GUI. Escape or Cancel will exit the dialog without selecting the color.
The Printer Dialog:
When the users decides to print his current file/document/image, he/she will be presented with this dialog, it will offer printing options like orientation, printing quality and the likes. The user can cancel his way back to the main GUI without printing or he can click Ok to begin the printing session.
Message Boxes:
This is the simplest of dialogs to make. It will allow to customize the title of the dialog, the message to display, the Icon to show the user (based on the dialog type) and the buttons to make available (buttons like Ok, Cancel, Yes, No and the likes). Depending on the dialog, pressing the buttons will either simply exit the dialog, or perform an action then exit to the main GUI.

Once again you can see the importance of planning a bit on a project like this. Some of you might be reading this and saying "duh, of course you need these!" that's easy to say because you can read them right here. But if i didn't include them, would you have automatically thought of them all? Think about that for a little bit. Again, listing them here gives a good idea on the coding ahead and helps to allocate time to the whole project in a much more accurate way.

IN CONCLUSION:

And this concludes the first part of this series. As you can see, we got our work cut out for us. But I think it's going to be well worth every effort. We've covered a lot of ground in this first part we've defined a lot of the functionality that we plan to have on our GUI project. Keep in mind that I'm using my own GUI project here, your project can and will differ from my own answers and my own vision of a GUI. The main purpose of this series is to tell you which questions you should answer, what details you should think about after you tell yourself "I want to make a GUI" and how to plan things out for the GUI itself and any or all the tools you know you want to include. It took me about 3 hours work to create this first part. Don't you think it really helps to define your GUI? I think so. If you just sit down and start coding, chances are you'll forget some important aspect of your GUI that might force you to start over (that's never fun). So taking a couple of hours, or even a couple of days to think about your project for a bit to make sure you cover at least most of the bases, will only help you in your project. A GUI is no small task to begin with, and you're only adding to the work by not planning ahead and just thinking and using common sense as you define and detail your GUI. What's a couple of days work documenting if it's gonna save you maybe even a couple of months of starting over the coding? Well worth it if you ask me.

In the next part of this series, we'll be starting the more technical side of GUI development. We already took the screenshot and broke it down into it's main areas, and that was useful to tell us the bases of how the GUI will work. In the next part, we'll define all the "controls" that will be needed by the GUI itself, each of these controls will also be broken down it's their main pieces and we'll see what we need to know about them in order to make them work as a whole integrate system it needs to be to work as a GUI. We've already defined some global keyboard standards, we'll need to define more as we refine the GUI design and we'll also define Visual GUI standards as they are needed just like keyboard standards. I hope you enjoyed this first part of the series. Until next time, maybe some of you might think about sitting down and documenting your efforts like this. in the long run, any project that should take more than 2 or 3 months to complete really benefits from good planning. If you have questions about this series, feel free to email me and let me know about it. Like everything else I write I like things to be crystal clear to those that read them. So let me know if something isn't clear. until next time, happy documenting, and coding.

MystikShadows
Stéphane Richard
srichard@adaworld.com

Download a copy of this tutorial.

Graphical User Interfaces - A Complete Study
Part 2 - GUI Details and Resources

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

Welcome to this second installment of my GUI Development Series. In the first installment, I told you about my own GUI project called ErgonOS, I detailed a bit what I wanted the GUI to do, defined some standard keyboard keys that will be available throughout the whole project, mentionned a bit what I wanted the GUI to look like along with some basic tools, utilies and resources. I think it's important to take the time to do this for a project this size just so you don't get lost in questions like "what did I want to do again?". But that's just the beginning. There's alot more to plan for when creating a GUI project. I call the first installment "The tip of the iceberg" and rightfully so as it talked about what the user would/could potentially see in the GUI.

In this second installment, We will break things down even more. We will take each part of the GUI as defined in the first installment and really take them apart to see exactly what each part needs as far as resources go to compose istself properly. You might be surprised to know, for example, that my scrollbar takes 8 distinct elements (plus 6 others for the pressed buttons) which brings the total to 14 elements for just a scrollbar. But you'll see how it's broken down later in this document. This is what we'll do in this second installment. It will form a very detailed list of things to do and implement which is a great tool to have when developing such a project. If any element is dependant on another it will be duely noted and we'll also start to define what events are and how they are to be considered in this project. So let's get right to it.

GUI DESIGN ESSENTIALS:

When you design a GUI's visual aspect, there's really three things you need to think about. It's important to take the time to really related these three items because in the end, they will govern the outcome of your project. When you think about it, there's more to a GUI than the way it looks even though the visual aspect of your GUI will be the first thing your users will see, it won't be the only thing they'll judge your GUI by. I've personally seen GUIs that looked like hell (in that case it was very bad color combinations) but were, in my book, as functional as they could get. I've also seen exquisitely beautiful GUIs that offered no functionalities (or atleast far from enough functionalities) to be usable. I've also seen GUIs that presented a good balance of these two aspects but seemed incomplete in design because some essential features just weren't there. Although a GUI is definitaly a question of personal taste, there's alot more to it than that. Let's take a look at these three things and explain them right here in what I believe is their order of importance in consideration.

Functional Design:
A component is what many would call a control. For example, a TextBox, a ComboBox, a clickable button, and the likes. When I say functional design, it's important to understand that how it looks has nothing to do with how it works. When you display a textbox on the screen, you have to ask yourself what could the user want to do with that textbox. In other words, the way you plan on making your components work is the first item on the list. Once you know how it will work, how it looks will be a simple question of giving it a look that fits (intelligently) the intended functionality.

Component Relationship Design:
Most controls work fine on their own. A textbox is a textbox plain and simple. However, some conponents will be destined to work in combination with other components. A Scrollbar doesn't do much by itself, it will typically need something that will get affected by the events it handles. For example, a scrollbar might affect the visible area of a grid or a picture. It might affect the values of a variable (for a color selector), but by itself, a scrollbar is a component that doesn't have any real valid functionality. You'd be surprised at how many people forgot some simple thing like that which represented a major redesign of a big project. Taking the time to see how controls could work together will often solve this issue and avoid some major design issues as you'll see later in this series.

Visual Design:
At this point, you know what you want your control to offer to the user, you also know if and how a given component will depend on another componement or be depended on by another component (inter-component communication). Once you know this, you can sit down and give your component a visual look. When I designed the ErgonOS screenshot you've seen in the first installment, I took the time to think about the functionality and relationship of what you're seeing in the design. Everything is where it is for a reason.

You'll notice quickly I'm sure that I put visual design as the last item on the list. There is a reason for that. Knowing how a component works and what other component it can work with (if any) can and usually will influence the way it looks. There's visual aspects of a control that wouldn't look the way they did if the given component didn't interact with other components or they wouldn't be positioned where they are in the visual design if they didn't interact with other components that you'd typically see nearby. GUI design is all about common sense and a good level of user interaction. Speaking of which, user interaction should be considered throughout these three aspects of component design because GUI does mean Graphical User Interface and as such everything about a GUI should have to do with what the GUI allows the user to do and the way the user can perform those features. In a standard GUI you have to consider that the user might use the mouse or the keyboard to perform an action (in some cases, a joystick if designing a game or if you want your GUI to work with a joystick like it would with a mouse.

USER INTERACTION EVENTS:

As you know, with any programs but especially with GUI projects, one of the most important aspect of the program is the way it interacts with it's many components AND the way it interacts with the user. Both of these are really important for an application to be complete. In the context of a GUI project, this type of interaction are even more important. As a general rule of thumb, you should never leave your user in the dark as to what is happening at a given time. If the GUI is just waiting for the user to do something, you should have a direct means of letting him or her know that the GUI is waiting for them. If an application in your GUI is busy doing something "important" and the user should just wait, again he or she should have a way of knowing that. Before anything else, it's important to define what the user can do at any given time. So right now, let's take the time to define the actions that the users can perform in the GUI. Typically, they are split into two major groups of actions keyboard and mouse actions. Depending on the the hardware installed, a joystick could be used, a lightpen, a tracing table but they all amount to keyboard and non keyboard events.

Keyboard Actions:
These are the oldest of actions. Keyboard have always existed since the dawn of computers and everybody uses them. Even today alot of users prefer the keyboard over any other type of input device. Although the choice is up to the GUI developer, me, I prefer to accomodate for both mouse and keyboard actions of not for anything else, to offer a backup system in case the other input device fails. This way, the user doesn't have to go buy a mouse right away. But I do this especially because alot of users are just keyboard users and would rather use the keyboard even if they have a mouse isntalled and working. Each key on the keyboard has a scancode and that code differs when ALT or CTRL or SHIFT is pressed in combination with the key. A keyboard manager simply needs to get these codes from the keyboard and branch out to the proper code fragment in the program depending on which part of the GUI the user is in when he presses the keys on the keyboard. At a global level, the keyboard standards I defined in the first part will be implemented. Because of such function as Shift and arrow keys which will allow to select text in a tet editor keyboard events will be broken down into 3 steps, the key down event the key press event and the key up event (when a key is released).

Mouse Actions:
This is where the code will vary alot depending on where the mouse pointer is (on what type of component). At a general level the user will have the ability to perform the following actions on any component that is currently visible on the screen:
- The user can move the mouse pointer around the whole screen. We'll need a way to determine where the mouse is on the screen but only in the case where the user pushes a button in most cases. However I want to implement a mouse over event to highlight the control that is currently under the mouse pointer as a visual help to the user, an indicator of which component on the screen will be activated if the user presses on a mouse button. The mouse over will be implemented on each component so when the mouse is over a component, the component will be responsible for knowing that the mouse is over it and highlight or unhighlight itself accordingly.
- The user can push a mouse button for two reasons, either to click or double click on a component or the user may push a mouse button to initiate a select of text or an area of a picture. In all cases each button on a mouse have a different value so we can determine which of the buttons were pushed. Because we'll want to allow selection of an area or dragging of elements to other locations, a mouse event is broken down in 3 steps, the mouse down event (when the user pushes down on a buton) the mouse press event (when the user just released the button he or she just pressed and the mouse up event (this is when the user finished releasing the button and will also help identifying if a possible double click of the button has occurred. Like windows, I want a click of the right mouse button to bring up a context sensitive menu for the current document in the document area (top right) section to give direct access to commonly used functionality.
- The user can perform a drag event which is a series of steps that start with a mouse button down event, a move of the mouse pointer while the mouse down event is still active (this will allow the dragging of a component or the selection of text or an area of a picture or whatever else that can be influenced by a drag event such has the scrolling of a scrollbar for example). There are many reasons to use a drag event, we'll see which component will need to handle later in this document.

With all this material in mind, let's define the ErgonOS components. We'll start with with simple components and work our way up to the components that are combinations of other components. This will also guide us in the rest of the series as to how we'll code ErgonOS and the techniques we'll use.

ERGONOS GUI COMPONENTS:

Here I'll be enumerating the elements, describing them along with any relationship that could and sometimes should exist between one or more other components. I will use a table format to help keep things clear and organized. Here we go. Note that if components are similar in nature I will group them in one table and merely explain the differences. I will explain the different actions and events after I enumerate them in this list of components.

Standard Label Component
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	LabelControl User Interface and Communication No other controls No other controls No derived controls Move, Resize, Enable, Disable Drag, Move, Drop Could get clicked but not necessarily.
Description:	The label is the simplest component that can exist in a GUI however it's practically the most useful to the users as they give the user information and/or explanations about certain other controls (labels to a textbox entry for example). They can be used anywhere in a GUI design where the need to explain or give information to the user is necessary (just as error messages, confirmation messages and the likes. Titlebars to dialogs can also use labels to display title information. Labels are usually not directly controled by the user. However, you could, for example, create a link in a label that can be clicked by the user to open a website in an explorer.

Standard Button Component
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	ButtonControl Accessibility, Selection No other controls No other controls Group Buttons, Toolbar Buttons, Scrollbar Buttons Move, Resize, Select, Enable, Disable Click, Drag, Move, Drop Enter Key and Focus events, Arrow keys (if moving)
Description:	The Button Component is the most widespread control that can exist in a GUI project. Sooner or later One or more parts of a GUI will need some form of button (text or graphical) to confirm somekind of action in the case of dialogs for examples. They are represented by a rectangular area that can be clicked on by the mouse. Group Buttons work together as a group and typically allow one or more options to be selected at one time. They can also function as radio buttons would and only allow one member of the group to be selected at once. Toolbar Buttons are typically square but could be rectangular. Like other buttons they can so text and/or images. Scrollbar buttons are smaller than toolbar buttons as they need to fit in a more limited space (at the bottom of a vertical scrollbar or on the right of a horizontal scrollbar component, they only show small images and no text.

CheckBox/RadioButton Components
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	CheckboxControl, RadioControl Selection Labels for text part, other radio components as a list No other controls No Derived Controls Move, Resize, Select, Enable, Disable Click event Space Key and Focus events, Arrow keys (if moving)
Description:	There's two major roles to the Checkbox component the first of which is to allow to select an option as being enabled or not. Another (fairly used option) is to represent a status of a series of operations where the option being completed gets checked so the user can see how many steps are left. The radio component can also be turned on or off however it needs to be in a group of other radio controls to achieve it's intended purpose as it allows to select one and only one of a series of options.

TextBox, MaskedBox, SelectorBox Components
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	TextBoxControl, MaskedBoxControl, SelectorBoxControl User Input No other Controls No other controls No Derived Controls Move, Resize, Select, Enable, Disable, Entry Click event, Drag Event (for selection) All Keys and Focus events, Arrow keys (if moving or resizing)
Description:	In ErgonOS these three components allow one line only of filtered on non filtered entry from the keyboard. Whenever a value (string or numeric) is expected from the user, it is often in a textbox component that this value can be acquired from the user. MaskedBox components offer the same with the added feature that the input can be controled by providing a mask (or filter) to what keys the user can push. for example a mask of "##,###.##" would only allow the user to enter numeric values. This is useful for data validation techniques. A SelectorBox could also be called a range validator component and can be used when a list of expected values is acceptable. Note that a listbox or a combobox component could also be used for this purpose. Depending on the role of the input a selector box could be faster and just as safe.

PictureBox Component
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	PictureBoxControl Display, Image Editing No other controls Scrollbars if image bigger than picturebox No derived controls Mouse Movement, drag, drop, select All Button Click, Drag, Drop. Arrow keys, PageUp/Down, Enter, Shift Arrows (Selection).
Description:	What's to say about a picture box exactly? In this case, the picture box will allow complete editing of images of course. It will also allow the loading and displaying of image files of many formats. Aside the standard expected image functionality, i will also support zooming in and out, color depth manipulation and a couple of advanced functions to make the image box a little bit more useful than most standard picturebox component. As mentionned, should the image being displayed be larger than the current size of the picturebox component, a set of scrollbars will be available to navigate around the image.

ListBox/ListView/TreeView Components
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	ListBoxControl, ListViewControl, TreeViewControl List management, Hierarchy and Basic Grid No other controls Scrollbars if list is bigger than the listbox ImageList and ImageListView Mouse Movement, drag, drop, select All Button Click, Drag, Drop. Arrow keys, PageUp/Down, Enter, Shift Arrows (Selection).
Description:	This set of 3 controls I've combined here because when you think about it, they are all some form of list managers in their own right. The listbox is the most primitive of the three controls in that it only allows a list of one data element. A scrollbar appears when needed if there's more data than what is visible in the control, all controls work the same way. The ListView component handles more than one column of data but otherwise works as a listbox component. The treeview is a list however each item can have one or more child items which allows to handle a complete hierarchy of related and grouped items quite efficiently.

ComboBox, CalendarDrop, NumericDrop Components
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	ComboBoxControl, CalendarDropControl, NumericDropControl Selection, Data Entry No other controls Scrollbars, buttons, listbox, calendar and numericpad No derived controls Mouse Movement, drag, drop, select All Button Click, Drag, Drop. Arrow keys, PageUp/Down, Enter, Shift Arrows (Selection).
Description:	This set of 3 controls all have a standard textbox or maskedbox with a down arrow button on the right. while standard textbox editing is available, pressing the down arrow button will, in all three components, brings a more visual means if entering (or selecting) valid data for the textbox area. Since they all bring down a different means of data entry, I grouped them together here. Of course the combobox will bring down a list of selectable items (much like a listbox), the calendar component will bring down a calendar from which to select a valid date and the numericdrop component will bring down what looks like a calculator (numeric keypad) to select each digit that are to be entered in the text area.

Toolbar and Toolbox Component
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	ToolbarControl and ToolboxControl Selection, options, menu shortcuts No other controls Buttons, Combobox and others for representation No derived controls Mouse Movement All Button Click Tab key to select, Enter key to activate.
Description:	These two components are really one of the same, they are a rectangular area that are used to hold mostly button components (but can hold other types of components as well). The main difference between these two components is one of standard. The toolbar will hold menu shortcuts only while the toolbox can hold tools and accesories that can be used with the current document type. If you remember I mentionned in the first part that each document can customize the GUI for it's own use. These are two of the four areas of the gui that can be customized for the type of document. These components are around the main document area (the toolbar is below the menu system and toolbox components can be anywhere around the main area (top, bottom, left or right).

ComboBox, CalendarDrop, NumericDrop Components
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	ComboBoxControl, CalendarDropControl, NumericDropControl Selection, Data Entry No other controls Scrollbars, buttons, listbox, calendar and numericpad No derived controls Mouse Movement, drag, drop, select All Button Click, Drag, Drop. Arrow keys, PageUp/Down, Enter, Shift Arrows (Selection).
Description:	This set of 3 controls all have a standard textbox or maskedbox with a down arrow button on the right. while standard textbox editing is available, pressing the down arrow button will, in all three components, brings a more visual means if entering (or selecting) valid data for the textbox area. Since they all bring down a different means of data entry, I grouped them together here. Of course the combobox will bring down a list of selectable items (much like a listbox), the calendar component will bring down a calendar from which to select a valid date and the numericdrop component will bring down what looks like a calculator (numeric keypad) to select each digit that are to be entered in the text area.

MenuBar, PullDownMenu, PopupMenu Components
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	MenuBarControl, PullDownMenuControl, PopupMenuControl Selection, options No other controls Option bitmap icon of the menu option No derived controls Mouse Movement Left button click Arrow keys to navigate Enter key to activate.
Description:	A menu system is typically a combination of these three types of menu components. The menubar is the first visible to the user. In ErgonOS it is right below the titlebar on top of the main document area. when the user selects one of the options in the menu bar, a pulldown menu will appear with relative functions and options. Because it will appear below the selected menu bar option, it is said that it will pull itself down which gave birth to it's name. If other levels of menus are needed, popup menues will be used. This same popupmenu will also be used for the right button click functionality I mentionned earlier in this document. In the pulldown menu and the popup menues, an optional bitmap may be used to give a visual representation of the menu option (when these are added to a toolbar, only that bitmap will appear) This will help locate what the button does because the user will see it in the menu system with a description. These controls can also be customized on a per document type level to offer the most relevant functionality needed when working on a certain type of document (that works just as well if he document is a game for example).

Statusbar and IndicatorBar Components
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	StatusBarControl and IndicatorBarStatus Information and user feedback No other controls Labels and optional bitmaps No derived controls No actions, for display only No Mouse event except possible mouse over and click No keyboard events.
Description:	Both these controls appear on the bottom of the main document area and server to represent information about the current document. The statusbar component will mention things like the document name, it's type, if it's modified or not and the likes (definable by document type). the indicatorbar will tell you where you are in the document (rown and column) as well as if you are inserting or not, if your caps lock key is pressed or not and other "editing" related information, it could be X and Y coordinates on a picture for example. Again it can be customized on a per document type level so each document can give relevant feedback about itself and is being done currently by the user.

TabbedDialog and TabStrip Components
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	TabControl and TabStripControl Selection No other controls Label, optional Bitmap Icon, Page Container No derived controls Mouse Movement Left and Right button click Tab key to select which tab is active.
Description:	In ErgonOS, the best example of Tab usage is the main document area. When you open a new document (whichever type it may be) it will create a new page in the document area And will appear right below the main document editing area. Selecting one of these tabs will essentially setup the whole GUI for the document type (including menues, toolbars, toolboxes and accessories toolbox at the bottom right of the screen). In this case the tabs work much like the windows taskbar where each page will be an application or a GUI setup for the document type. When you click on the document configuration tool, another use of tabbed dialogs will be available as the functionality and options for that given document type will be shown in a tabbed dialog grouped by functionality in different tabs. IF an application needs a data entry screen and there are too many different bits if information required for just one screen, using tabs will allow to create entry screens that are on more than one page. Tabs provide a quick and intelligent means of organizing multiple screens of related information. Each page uses a page container so that it can contain other controls or document to achieve the desired functionality of the new page.

Document Management Component
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	DocumentControl Entry, Selection, Visualization, Editing No other controls Document Filters per document type No derived controls Mouse Movement Left and right button click, drag, drop All keyboard events for editing, selecting, etc.
Description:	A document, in the case of ErgonOS can be considered as a document and/or an application since each document type govern the overall look and behavior of the whole GUI. Hence if you were to make a game for ErgonOS it would appear as a document page in the main document area. More than one page representing one document will also be allowed. For example, if you were working on an HTML document you could define a page for the HTML code itself and another page for the HTML preview. Tabs on top of the document area (below the menu and toolbars) would then appear for each representation of the same document. Another example is XML files. In many cases You'd be editing XML code, XDT files for data definition and XSL files for data representation and formatting. the three files could be paged the same way in one document since they usually work as a group towards a finished validated and formatted XML document. A game could have more than one page as well. For example, the first page could be the main game, the second page perhaps a map of the different levels when needed and the likes. Each document can be setup to represent itself in different ways. A plain text document would just output regular characters, a source file could have a syntax highlighting feature applied when editing code, a word processing document could show different fonts, colors and images in it's contents. Of course you could use the supplied functionality but you could also provide your own. So essentially, defining a document's views, behaviors, tools is the first part in building an application setup for the document type. in addition to that, you could also add a document editing and viewing options to allow you to add syntax highlighting or text formatting features to your document. You could either use known standard keywords and tags or define your own. More on this when we cover ErgonOS Application Development facilities.

User Definable Component
Control Name: Control Type: Depended on by: Depends on: Derived Controls: Action Types: Mouse Events: Keyboard Events:	UserControl Application Creation, Functionality filtering No other controls All other components and other user components No derived controls Mouse Movement, kebyard action, mouse buttons Selectable Mouse Events (all possible) All keyboard events (can be customized)
Description:	So far, the components I've defined all follow the ErgonOS standard as in they are all made to work with what ErgonOS offers in terms of functionality, look and feel. This UserControl components allows the user and developer to create 100% customized look and feel for their documents (applications). Later in this series, when we create our home financial application, we'll see how this control can be used in so many ways to give a document type it's own unique look and functionality based on what the document should be allowed to do. We'll also see example of the multiple paged document usage too as the application will need all these features to perform it's designated task properly. For now, all you need to know is that the User Component allows things to appear and work completely based on what the user need and want from a given document type. Functionality filtering could easily be used as a security measure where when you allow others to use the system you might not want them to edit any files any editing feature could be block with a simple click of a button or by creating a functionality filter for the current document type.

And there you have it, this represents the many controls that are used in ErgonOS. With the UserControl component you could create your own if you want a specific component that just doesn't exist in ErgonOS. Of course, to make it all work together in a coherent and intelligent way, we'll need some basic things implemented. Groups of related functionality that all serve to perform a given set of tasks are often called engines. And ErgonOS will definitaly have engines to allow it to offer the users a suitable and usable interface to the low level functionalities available on the OS it will be built on. Let's take a brief look at them so we know better what we'll be up against when we start to code the GUI.

ERGONOS ENGINES:

The engines listed here represent independant areas of functionality that is needed for ErgonOS to work like it is expected to. Each engine is independant in itself but could receive, if needed, events and information from one or more of the other engines. Here are these engines along with their description.

L.A.H.P. (Low level Access to Hardware and Peripheral)
In this first phase of ErgonOS development, this level will just be an interface to BIOS information however I will keep that part independant so that ErgonOS can be quickly made to work on any other architectures. if you need to know information about the hardware in the case, this is what will give that information. This should work fine in any PC based system in this first phase.

V.A.D.M. (Video Access Device Manager)
Although I've decided to use the Allegro library for most video functionality you'll be seeing, there is still plenty of functionality that I'll need to code for. For example, screen saving and restoring for when forms and dialogs appear on top of the GUI the screen will need to be restored after the form or dialog is closed. I'll also need this engine to have knownledge of where all components of the GUI are so I know which event manager to call when a user event occurs. This is the engine for the job. Using allegro (and derivatives) should allow the Visual side of ErgonOS to work on any platform and OS that supports the allegro library.

O.S.S.I.S. (Operating System Services Interface System)
All operating systems work different when it comes to using the hardware connected to the PC. DOS will use interrupt 10h for video, 33 for mouse, 21 for OS services. Linux will use a different system and the same goes for other OS on other platforms. In this first phase, DOS will be implemented. But in later phases, I plan on being able to run Ergon OS on amigas, Macs, power PCs and other architectures that differ greatly from one another. So this part of the engine will be kept independant of the other engines so they can be adapted to different platforms and OSes as easily as possible.

A.S.D.A.M. (Architectural System for Digital Audio and Music)
If the OS can see a sound device in the system, A.S.D.A.M. will be initiated and read for action. It will also allow facilities for opening and creating standard MIDI files and wav/mp3 files in preparation for multimedia presentations or games. It will offer a set of standard functions coherent on all OS and platforms that will interface itself to the OS's provided drivers or architectures for sound synthesis and digital audio that are installed.

A.R.M.S. (Advanced Resource Management System)
ErgonOS uses resources thoughout a session, it will load appropriate bitmaps for controls and forms, it will unload what is not need at the current time. This engine is what will take care of that internally. It will get notified by the GUI that certain components and images aren't needed and ARMS will get rid of them in memory. Garbage collection will also be managed here. Note that the global ErgonOS Clipboard functionality will be managed from this engine as well so that anything that is cut or copied can be made available to other documents.

T.E.M.S. (Tasks and Events Managmeent System)
In ErgonOS each document type currently opened represents a task, Each task has it's own page so to speak. However some pages will have multiple pages to represent themselves. Each component that can be seen will have it's own event manager. The current task will determine which document gets the user events (along with which of the general ErgonOS areas are clicked on or keyed to with the keyboard). This engine will determine which area of the screen the event goes to as well as which task it belongs to all the way down to which component the mouse was over when the event occured to know which event manager to call.

C.A.P.S. (Command Acquisition and Processing System)
Remember the command window from the first installment of this series? This engine is what will get any and all commands typed in the command window, determine if the command is valid, and execute the commands (which could mean bringing up a file dialog to open a file, setup a document type's many customization features, create a project group in which files will be organized for the sake of user ease of use and personal organization of his files or whatever else is offered by the GUI in terms of feaures and functionality. These commands are global to the whole GUI unless a given document type has been given a specific set of commands that are active when the type of document is being worked on. For example, if you are editing a webpage, you could say that for HTML files PREVIEW will automatically activate the preview tab of the document. and really customize even more aspects using custom commands. This engine will also allow to create what I call ErgonOS Job Files which are specific list of ErgonOS commands that can be executed much like a DOS Batch file.

E.A.G.L.E. (ErgonOS Application Generation Language and Environment)
On top of CAPS which can be directly incorporated into an EAGLE application for GUI setup purposes for example. EAGLE will also have all the statements needed to create variables, perform conditional testing and evaluation, itterative constructs and procedures to organize the code into a modular fashion. It will also allow object oriented programming extensions (I call it extensions because OOP will be optional, not mandatory in EAGLE development projects).

This is of course a work in progress. It represent the engines I can think of right now. I think they are complete and that if they have been mentionned they shouldn't change too much. However, as development goes by, I might add to this list of engines if I think of a major group of functionalities that I simply didn't account for when enumerating them right here. As you can se, I'll have my work cut out for myself but it should be a very interesting experience. All these engines are there because of the way I want ErgonOS to work. It is very likely that for your own GUI projects you might want things to work very differently from ErgonOS and rightfully so. This series represent everything that will go in ErgonOS as per the way I will want ErgonOS to work internally and from the user's perspective. Of course your GUI project might have some similarities to mine. But this series of articles should be used as a set of guidelines for ALL GUI projects. But rather as a list of things you may want to consider when creating your GUI. Sitting down and thinking abit about what your GUI will be used for and what it should have based on it's intended purpose will help you define what parts you'll want to use and which part have no meaning to the purpose of your GUI.

PART TWO NOW CONCLUDED:

This brings the second part of this series on GUI development to an end. It also brings alot of the "documentation part" to an end as well. In the next part we'll still be documenting a few things of course but all documentation will start aiming at the coding side of the GUI rather than the design side of the GUI. So I suggest you take the time for these first two parts to sink in as good as they can before we attack the third part of this series. I've mentionned alot of things in these first to documents. Maybe by now some of you might already be thinking of how you can use some of this material for your own new or existing GUI projects. Can you imagine just how prepared documenting the GUI design helps make you? it took me a couple of hours and look at how organized things are getting in this project so far. These first two parts will really help define the rest of the series right down to the coding part and this is what planning is all about.

In the next installment, as I already mentionned, we will be starting on the coding side of ErgonOS. Like I said I will be documenting that side too but as you'll see it will all be about coding. Until then, if you have questions, comments, suggestions or if you just want to say hi, you can email me at the email shown below. Until the next installment, happy reading and planning.

MystikShadows
Stéphane Richard
srichard@adaworld.com

Download a copy of this article!

C++ For the Basic Programmer: Part 2

Written by The Awakened

Welcome to part 2 of my C++ series. This month, we're going to look at prototype declarations, variable scope, strings, pointers, heap memory, and classes. Just so you know, by default, I'll use the term QB, but it's also compatible with FB. When I say FB, generally, I mean that only FB can handle it (such as Windows stuff.) Let's jump right in.

Prototype declarations are the same as when QB automatically puts a "DECLARE SUB" at the beginning of your program. See, if function main calls function x, before function x has been declared, main has no idea if the arguments are of the proper type, or if the return type is proper. You then get a compiler error. So lets say you have function x:

int x(double y, unsigned b)
{
	//do stuff
}

You want to make sure you put the prototype before the call is made. A prototype looks like an empty function, but with a semicolon at the end. Observe:

int x (double y, unsigned b);

And there you have it. Put that at the beginning of your program (like after "using namespace std;") and your're set. Moving on...

You probably know what "variable scope" means. If not, it just refers to whether other functions can use the variable or not. To declare a global variable, you've gotta declare it outside every function, even outside main(). So you could go like this:

#include<whatever>
using namespace whatever;

int x;
float a;

int main(int nNumberofArgs, char* pszArgs[])
{
	x = 3;
	cout 	<< "the global variable of x is"
		<< x
		<< endl;
system("PAUSE")
return 0;
}

And hopefully, it would say "the global variable of x is 3". Note that you have to change the values of the variables within a function. You can't do it in the space where you declared them (kind of a no-man's land... or maybe not, heh)

Next up: strings. Last month I told you that all you needed to do was include the <string> file, and you'd be set. Well, unfortunately for us, the Windows API (and probably a whole lot of other API's), and probably many coders, don't use this. Instead, they use an array of "char" variables, and the last character is a null character, ie., CHR$(0). This is called a "zero-terminated string". Here's an example:

char mystring[]= "foobar";
//here's the same thing
char anotherstring[]= { 'f', 'o', 'o', 'b', 'a', 'r', 0);
//yet again
char yetanotherstring[]= { 'f', 'o', 'o', 'b', 'a', 'r', '\0');

Okay, notice that in the first one, it's just the string, but in the next two, you've gotta put a zero in there. When you use the double quotes (""), it automatically tacks the zero at the end. If you want to put the zero in quotes, you have to put a backslash before it, kinda like \endl. So in each of those cases, it's a 7 character length string.

Guess what? FreeBasic does this too for the String data type. You can't use the CHR$(0) in a string because then the program thinks it's the end of the string.

And if you want to display a string, you have to set up a for loop. The nice thing about zero terminated strings is that 0 itself is the value of "false". So in a for loop, for the conditional, you can set it to run through the array until it reaches a 0, or false, value. Here's an example:

for (int x = 0; mystring[x] ; x++)
{
	cout << mystring[x];
}

And it'll terminate once it gets to the 0.

Next up: Pointers. If you didn't already know, a pointer is a variable that contains the address of another variable. If you're not really sure about pointers, there's some tutorials on the FB Wiki about them. Anyway, the & operator gives you the address of a variable. So you could go:

int a;

cout << &a << "\n";

and it might output

or some other memory address. This is the same as FB's @ operator.

The * operator has two uses. An example is in order here.

int variable;
int* ptrvariable;

//The first line declares an int variable, and the second line declares a variable that will point to an int variable.
//The * character can be anywhere in between the "int" and the pointer variable name.
//ptr variable is not techically an int variable, but it will be used to point to another variable.

ptrvariable = &variable;
//now ptrvariable points at variable
*ptrvariable = 10;

//this does not change the value of ptrvariable! Because we used the * character, it instead says "the variable at the
//memory location that ptrvariable stores, equals 10 now."

So essentially, what this code has done, is changed the value of variable to 10. You can think of ptrvariable as a middle man. Make note of the * character. Remember the parameters of int main()? The second one is "char* pszargs[]". The "p" in "pszargs" stands for pointer, and "sz" stands for "zero terminated string", like the ones we saw above. So it points to wherever the arguments of the program are (we might get to using them in a later chapter).

Now, pointers can be fun, but remember, any variable that is declared in a function is gone when that function ends or calls another function. Now, for smaller programs, that means just declaring global variables, but in larger programs when memory is a bit more precious, there's an alternative. It's called the "heap". Basically, it's a huge block of memory that exists to be used when called upon, and then returned when the programmer chooses to. That way, you don't have to hog a bunch of memory with global variables.

A great way to do this is to set up a function that _returns_ the address of a block of heap memory. To create a variable from heap memory, you use the "new" keyword, followed by the type of variable you want it to return. So here's a function that does that, and then a different function that calls it to create a new variable, and uses it:

int do_Stuff(void)
{
	cout << "let's make a variable from heap memory! Initialize int variable!" <<endl;
	int* pnStuff = heapInt();
	//call heapInt() to make an int variable from the heap. Skip down now and read through heapInt().
	
	*pnStuff = 3;
	
	cout << "ooh! Our new variable is " << *pnStuff << "!" << endl;
	cout << "Let's call another function to make sure our precious variable doesn't disappear!"<<endl;
	
	do_Nothing();
	
	cout << "our variable is still "<< *pnStuff <<"! Sweet!" << endl;
	cout << "well, time to say bye bye to our heap variable! delete now!"<<endl;
	
	delete pnStuff;
	pnStuff = 0;
	
	//AHA! We didn't have the asterisk character in there! We didn't ask it to
	//delete whatever was in the variable, we asked it to delete the memory address, which
	//is what pnStuff is holding, and return it to the heap. The rest of the time we were
	//asking it to manipulate the stuff at the memory address that pnStuff holds! We also
	//reset the pointer to 0, just in case we accidentally try to use it later in the
	//program.
	
	return 0;
}

int* heapInt(void)
{
	int* x = new int;
	//the new keyword allows us to allocate memory off of the heap. The memory address is stored
	//in x, and then...
	return x;
	//we return that value to the statement that called it.
}

void do_Nothing(void)
{
	cout << "here we are in another function." <<endl;
}

You might be confused, so let's go through line by line.

First, we have a function called do_Stuff(void). It prints some text. Then it calls heapInt to return a pointer to a new integer from the heap. Note the syntax when we use the "new" keyword. We're declaring a variable, but we're saying "okay, we want this new variable to point at an integer off of the heap". We could have even gone:

int* x;
*x = new int;

As it's the same thing, but the one I have up above is just shorthand.

Remember! x is not technically a conventional variable. It points to a memory location that "came off of the heap". So then, using the * operator, we change the variable to 3. And then we print it to the screen. Then we double check that we still have the memory address available to us (and we do.) Then we free up that memory by "deleting" the memory location. Then, just to be safe, we set the pointer to 0, so it can't do any damage. :)

"But, why bother with the heap? Why not just have a function that returns the memory address of a normal variable?" Oh, like this?

int* createInt(void)
{
	int localvariable;	
	return &localvariable;
}

The problem is, that the memory that localvariable occupies is freed up the moment the createInt function loses focus. So you'd be pointing to memory that could be in use for some other program. Not good. Let's move on.

Before we get to classes, we should discuss the less complicated thing: structures. They're the same as QB's Types. Syntax is as follows:

struct wake_up{
	int x;
	float y;
	double d;  //tee hee hee!
}

wake_up The_Awakened;	//creates an instance of the wake_up structure, called The_Awakened

The_Awakened.x = 3;	//changes x to 3, in the The_Awakened struct

It's the same as going, in QB:

TYPE wake_up
	x AS INTEGER
	y AS SINGLE
	d AS DOUBLE
END TYPE

DIM The_Awakened AS wake_up

The_Awakened.x = 3

Easy enough? Good... because...

It is time... for CLASSES! AND OBJECT ORIENTED PROGRAMMING! HAHAHAH!

Excuse me...

This is a major part of the C++ language. It's pretty much what separates C from C++. And according to v1ctor, FB will soon have OOP support as well. So here's your headstart. ;)

Object oriented programming is basically a collection of commands/techniques that are intended to reduce the complextity of your code. Which in turn saves you time in development, debugging, and modification of your code. Now, one thing it WON'T do, is magically make you a better programmer. Just because you code in an OOP language, does not mean you automatically write proper OOP code. Kinda like how QB has subroutines, but that doesn't stop you from using GOTO's. Not that GOTO's are bad. Nor are functions. Each has their purpose, but OOP is, as I said, designed to reduce the stress of coding and all that follows from that.

We'll start with some abstract thinking first here. The whole object oriented thing can be thought of in terms of real world objects, for starters. As an example, you can divide objects up into 2 categories: living, and non living. You're a living thing if you eat/drink, respond to stimulus, etc. Everything else is non living. This is called classification. From living things, we have plant, and animal. We could go further, to say that there are many different types of animals... mammals, fish, reptiles, etc., that all have the properties of the catagory of "living thing". To go further, there are many types of mammals: bears, deer, humans, etc. They all "inherit" properties of the previous catagory.

But what if a behavior of a certain class is different from all the classes it has inherited from? The first thing that springs to mind (heheh... springs to mind) is that humans are the only creature in the world that have intercourse for fun. (Correct me if I'm wrong, though, heh.) Suddenly, that behavior must be changed, without messing around with everything else in a human. This is called polymorphism. We'll jump into some more concrete stuff... now.

Let's start with Classes. Honestly, as dumb as this sounds, a Class is like a QB TYPE, but it allows you to put Subroutines and functions in as well... with a few added benefits. You can have variables of the class as public, protected, and private. Public means that any other code in your program, and any code in other classes can access this data. Protected means that only the class itself can modify it's data. Private means the same as protected, but we'll soon find out the difference. So here's the creation of a class:

class Person
{
	public:
		string firstname;
		string lastname;
		int age;
};


Person Myself;	//we've gotta create an "instance" of the class,
		//kinda like DIMing a TYPE in QB

//change some variables

Myself.firstname = "Metal";
Myself.lastname = "Matt";
Myself.age = 17;

Now, note that you couldn't change those variables outside the class if we had changed the "public" to "protected" or "private". Also note that there's a semicolon after the closing brackets of the class.

As a little terminology, variables in a class are called members. Functions within a class are called member functions, or sometimes, methods.

However, we could do this with a simple struct. So let's make this class do something. Before we do, I'd like to talk about encapsulation. The whole idea behind encapsulation is to make the class seem not so complicated to work with. Let's say you've written a large program, and it calls a function in a class (called a member function) about 300 times. What if, one day, you decide you need to change it? Maybe it doesn't do what you need to. Rather than have to restructure your program (and you'll probably have to, a little bit) you can just change the member function of the class. The best example, once again, is Windows. Think about it, you can run Windows 98 programs in Windows XP. Why? Because Windows knows how to manipulate the data best, and create a window for your program, and create menu bars, etc. All the calls to the API that you make are compatible with any Win32 system. They look slightly different on 98 than they do on XP. You can't just start coding Windows API stuff, and directly set important variables about your application. If you did, Windows might get into a fight with your program, and it might crash, too. And you might be losing compatablility.

This brings us to the topic of Setters, and Getters. A big part of encapsulation is making variables either protected or private. It's considered good programming practice to use as few global variables as possible. So how do we set values in our classes if we make them protected? Setters and Getters. Once again, using Windows as an example, if you've coded the API, you'll notice some functions called "GetThis" or "SetThat". These are so you can set and get protected data. Windows doesn't want you to directly set them, because if you accidentally set the wrong variable, it'll crash. Of course, if data is protected, you can't get the value of it directly either. So that's where getters and setters come in. Here's a (sort of) practical example:

class NPC
{
	protected:
		int x;
		int y;
		int offset;
		//whatever else
	public:
		bool SetX(int xvalue)
		{
			if (xvalue < MaxX && xvalue > 0)
				{
				x = xvalue;
				return 0;
				}
			else
				{
				return 1;
				}
		}
		//do the same for the Y value

		void GetX(int *address)
		{
			*address = x;
		}
		//do the same for Y
};

Let's go through line-by-line. First we create a class called NPC (non player character, for those who've never played a game :) And we make the values of x, y, and the offset into the sprite array (just a quick example, probably wouldn't really do this) protected members. Then we create our functions. As a side note, when you're making a class, you can put data and functions in any order. By that, I mean that you can create a function that uses data before you actually declare it in the class. You could make the SetX and GetX functions, and then declare the variables afterwards. Right, let's move on.

So then we make our member functions public (it wouldn't do much good if the rest of the program couldn't call it either, would it? :) Now, I've set up some code, that checks the value that the coder puts in that he wants to set the x value to. If it's above the Max X value for the map (or whatever), then it returns a non zero value to the code that called it. To get the value, the coder must send the address of the variable that wants to "get" the X value. Easy.

For the most part, it's crap code, but it's a learning example. See, that's the problem with trying to teach OOP. The times when it REALLY comes in handy are huge programs. and that's a little out of the question when writing a tutorial.

If you want to call a member function, it's the same as accessing a variable:

NPC Guy1;	//gotta create an instance of the class

int result;

result = Guy1.SetX;	//set X to 3, and get the result of whether or not 3 is a legal value

if (result == 0)
{
	//everything worked. Good.
}
else
{
	//damn... that was an illegal value.
}

Yeah, useless example, but use your imagination and I'm sure you can think of some uses for it. :)

So let's finish up with inheritence. Inheritance creates a new class that gets all of the "parent" class' member functions and data. And then you can add stuff to it as well. Consider the NPC class. What if we wanted to make a class of shopkeepers? Assuming we've already created the NPC class, here's how we'd create a shopkeeper class that inherits from the NPC class:

class shopKeeeper : public NPC
{
	
	public:
	
	string items [10];
	int price [10];
	//etc
}

What this does is inherit all of the member functions of NPC, and leave the level of access the same. If we had said "class shopkeeper: protected NPC", it would have made every public member a protected member. If we had any private member functions, they would have stayed private. If we had gone "class shopKeeper : private NPC" it would have made every member private.

And now we can add more stuff to the class(and we just did.) We can set the x and y values because the NPC class had them. Like this:

shopKeeper Guy2;

int result;

result = Guy.SetX(4);

if (result == 0)
{
	//everything worked. Good.
}
else
{
	//damn... that was an illegal value.
}

Wow. We saved a bunch of time, not having to copy and paste. It also reduces the risk of error when copying and pasting, in terms of debugging.

Before we end, I'd like to make note of one thing. I promised I'd tell you the difference between protected and private. Well, private members don't get inherited. Protected members do. There are some situations where this can come in handy (none that I can think of, heh.)

Wow. That was a lot. I just spend all of today testing the code, making sure it worked (some of it didn't), and finishing up this edition of the tutorial. I need a Coke. Yes, a Coke, and then I'll go downstairs and play Quake for N64. I'm checking out a lot of 3D stuff, so I gotta play the classics... besides, it was $9 (Canadian currency too) at the used game shop, so who wouldn't? :)

And we still have a HUGE amount to cover. Lots of things involving classes (constructors, polymorphism static members, abstract classes), opening files, handling errors, and other crap I forgot to cover.

Please tell me if this tutorial is actually of use to you. If it's unclear, or there's any way I can improve them, tell me. I'm on Pete's boards.

Good luck!

-The Awakened

Database Design - A Complete Study
Part 4 - Database Reporting

Written by Stéphane Richard (MystikShadows)

INTRODUCTION:

Welcome to this, the 4th and final part of the complete database study series. As I mentionned in the 3rd part of this series, we will be covering the part of Structured Query Language that can help you draw useful information and reports from your database. We will be using the tables we defined in Database Design - Part 2 for the examples in this final part. These techniques should help you in any database related project you might have. It doesn't matter if your database is for business management, a list of contacts,or any other project, a table is a table and as such you can create reports from them just by using Structured Query Language.

The best way to learn is to follow examples and that's just what I'll give you. We'll start with some very basic, but still useful, examples and work our way to more elaborate reports. This will make the SQL statements more and more complex and should show you, gradually more of the things to think about when undertaking the more complex reports. It will also show you more SQL statement clauses that you haven't seen yet in the previous part of this series. With all this you should be pretty well equipped to do what you need with your database projects.

DATABASE REPORTING BASICS:

When you think about it, a report wouldn't give any useful information if the tables you're reporting from didn't have any data to work with. By this I mean that finding out if there is any data is one of the most useful report you can have. Of course, there are many criteria you need to know about when you're trying to find out if there's anything to report on. In many cases, a report will be based on dates. You'll want to know, for example, if there are any records in the database that fall on a specific date, or a specific range of dates. If you're working from the inventory table you might want to know what each inventory category that you defined is doing. This is useful, in this case, when you want to know if you're in overstock, that is if some of the products you bought just aren't selling enough so that you don't buy any of those the next time around. Likewise, there would be a great interest in knowing which products do sell so you can attempt to avoid having to backorder the best sellers. As a business manager you might want to know how much money you made this month, or this year so far. The list of reports you might need can be close to endless.

A lot of books you might read on SQL would do just what I did and use business examples for reporting. You might also notice that SQL statement and syntax is probably as close to the English language as it can get. The main reason for that is that SQL was originally invented for business executives. It was supposed to be a means of giving these individuals and easy tool to use to get useful information about their business. Once it was created though, many people simply didn't have the time to learn it or learn it well enough to do anything useful with it. So when you think about it, SQL is popular today because it was a failure at what it was supposed to originally do. Today SQL is used by programmers and database managers, but there aren't a lot of business executives that actually know SQL. Ironic isn't it? Thank you moneo for reporting that fact to me.

Whether it's for a business, or not, when you create a table or a set of tables, you need to ask yourself what can this table give me for information. Typically, the answer to that question can and would end up as a report (either a simple or a complex one). Now enough with the theories and reasons, let's get down to the actual reporting. No matter what answer you come up with when you ask yourself what a table can give back for information, since you are retrieving information from the database, you guessed it, all reporting clauses are added to the standard SELECT statement. So let's start shall we?

THE COUNT AND SUM CLAUSES:

I think these two names pretty much speak for themselves: COUNT and SUM. COUNTing and SUMmarizing are the best aspects of reporting. Very often you'll find yourself asking questions like “How many things did I sell?” or “How much money did I make so far?” In business, these are essential questions. COUNT and SUM are of course the best way to do it. Unless a simple select which would give you back all the records you're asking for in a list, COUNT will only give you how many of what you asked for. this saves you the task of counting all the records you'd get if you didn't use the COUNT statement. Here's a simple example.

SELECT COUNT(*) FROM InvoiceHeader;

This will tell you how many invoices you've created so far. In this example, I used COUNT(*) because it is acceptable, however, when your tables build up data, this won't be the best way to use the COUNT clause. It will be highly recommended to specific one field instead of the *. Consider a table with 100 fields and 3 million records in it. COUNT(*) is quicker to type but longer to execute than COUNTing a specific field since even if it doesn't do anything with the fields they are still all part of the query. So, to use just one field you need to specify it in a COUNT(FieldName) clause. For example:

SELECT COUNT(InvoiceDate) FROM InvoiceHeader;

Which field you use doesn't really matter as it's contents have no meaning for a COUNT since it only counts records in a table, not values of a field. If you want to know how much money that represent, you would use the SUM(ColumnName) clause. Here's an example for the SUM clause.

SELECT SUM(GrandTotal) FROM InvoiceHeader;

This will total all of the GrandTotal fields from the InvoiceHeader table and give you the total amount that all the invoices have. Now unlike the COUNT statement, SUM does consider field values and contents, So the Field you choose to put in a SUM clause must be of a numeric nature or it will return an invalid type error. All these short examples had to do with all the records of a table. Typically you can shorten the range of needed records. You might, for example, want to know many invoices you created so far this month or this year. You can do this by simply adding a WHERE clause to your select statement. Our Invoiceheader table has an InvoiceDate field and we'll use just that to determine how many records we need to consider for this report. Here's an example:

SELECT SUM(GrandTotal)
  FROM InvoiceHeader
 WHERE InvoiceDate >= '2005-01-01';

Simple as that really, this will give you back every record from January 1st to today. Say you wanted to know about the invoices for the month of september only, you would only add a condition to the where clause. Like so:

SELECT SUM(GrandTotal)
  FROM InvoiceHeader
 WHERE InvoiceDate >= '2005-09-01' AND InvoiceDate <= '2005-09-31';

As you can see, filtering out unwanted records is easy to do. It doesn't have to be a date field either. From the inventory table, you could want to know all the products in a given category. In this case, it's the same type of SELECT query. For example:

SELECT SUM(GrandTotal)
  FROM Products
 WHERE CategoryID = 10;

By adding AND and more conditions to this example, you could find out about more than one category at a time. Again it all depends on the answers to the question "what can this table or set of tables give me back for information?". Now you know how to filter the unwanted records. Next comes how to break the records that you do want into signicant parts. This next section will show you a new SQL statement that is perfect for breaking down these records into any kind of workable groups.

THE GROUP BY AND ORDER BY CLAUSES:

A perfect example of this kind of GROUP BY use is our inventory table. Some of the many questions any inventory manager wants to be able to answer are: “What do I need to order?”, “How much did I sell each month?”, “What are my hottest selling categories of products?”, and so on. Let's the the last question for example. As you can see in our table definitions, each product has a CategoryID field. By grouping the report on this field we can quickly find out how many types of products we have in our inventory. The SQL statement for this example would be:

  SELECT CategoryID, COUNT(ProductID)
    FROM Products
GROUP BY CategoryID;

Assuming we have 5 categories of products and typically more than one product for each of these categories, this example would return:

CategoryID
---------- --------
1          121
5          100
3          32
2          58
4          101

You probably noticed that the 2nd column didn't have any name. When you are using a function like COUNT() and SUM() it doesn't assign a name to that column. You can use the AS statement to give it a meaningful name. This is good practice especially when you have more than one of these calculated columns in a report. Likewise, if you were using a programming language like FreeBasic and wanted to get the value of that column, you couldn't do it if it didn't have a name. Here's the same example that will name that column Products:

  SELECT CategoryID, COUNT(ProductID) AS Products
    FROM Products
GROUP BY CategoryID;

Which would give you:

CategoryID Products
---------- --------
1          121
5          100
3          32
2          58
4          101

The same technique can be used to give better names to column headers if you feel they are not clear enough for the common user of this statement but if you took the time to name your field names properly, when you defined your table in the first place, you'll hardly need to rename them in a report. Note also that these categories are not in order, and many times your results won't be in the order the should be. The SELECT statement can be added an ORDER BY <FieldName> clause to allow to sort the result in any order you want them in. This Statement will order the categories for you.

  SELECT CategoryID, COUNT(ProductID) AS Products
    FROM Products
GROUP BY CategoryID
ORDER BY CategoryID;

As simple as that, adding that ORDER BY Clause essentially sorts the results in the field order you specified.

CategoryID Products
---------- --------
1          121
2          58
3          32
4          101
5          100

When using the GROUP BY clause, you can, add WHERE conditions just like any other SELECT statements. Let's say, for example, that we just wanted the first 3 categories for whichever purpose. We create our SQL statement like this:

  SELECT CategoryID, COUNT(ProductID) AS Products
    FROM Products
   WHERE CategoryID <= 3
GROUP BY CategoryID
ORDER BY CategoryID;

The where clause needs to be before the GROUP BY clause as shown in this example. You could use more than one condition too like any other SELECT statements. This particular example would return:

CategoryID Products
---------- --------
1          121
2          58
3          32

As a rule of thumb, it's very important that you remember one thing. If you're going to need to group by a certain field, that field must appear in your SELECT statement's list of selected fields. If you can remember that, a lot of unnecessary confusion can be avoided. So far it seems pretty simple doesn't it? By applying these techniques to any of the tables (maybe with different fields and querying condition) you can manage to get some useful information out of them. However, these example all concern one table at a time. The real power of SQL reporting is when you need information, presented in an intelligent and workable way, from more than one table. The next section will cover this aspect of reporting. It will combine what you've seen so far and integrate JOIN statements to mix tables together in a way that can't be done by simple SQL statements alone. But with these additions you'll quickly see how useful SQL was meant to be other than to maintain a table and it's data.

REAL WORLD REPORTING TECHNIQUES:

Keep in mind that the simple examples I've shown so far will come in handy because they can present you with information you need to know. However, when you can related 2 or more tables to create a report, things can begin to become even more useful. Once again examples are the best way to teach you reporting so that is just what I'll do. Let's examine a couple situations that are related to our table definitions and see how we can get the information we want out of them. Remember that if a select involves more than one table, in reporting, it will more than likely mean that you'll be using the JOIN statement.

As a first example, let's pretend that we want to know how many products were sold so far. However, to make our report a bit clearer to read, we will want to display the ProductName, it's price, how many of them were sold and the total amount of money it represents. Believe it or not, this type of question is asked very often in business. Anything that can give back how much money anything made is a question you'll hear often in your career as a developer. So then, taking this example, we know we'll need the Products table. since we want to know how many of them were sold we'll also need the InvoiceDetails table where each item sold is listed here along with the quantities sold. We'll want enough information for the report to be clear and easy to read so let's see what the statement can look like:

   SELECT Products.ProductID,
          Products.ProductName,
          Products.CurrentPriceSold,
          SUM(InvoiceDetails.QuantitySold) AS Quantity,
          SUM(InvoiceDetails.LineTotal)    AS AmountTotal
     FROM Products
LEFT JOIN (InvoiceDetails) ON (Products.ProductID=InvoiceDetails.ProductID)
 GROUP BY Products.ProductID
 ORDER BY Products.ProductID;

This example only uses two tables to get all the information it needs. The LEFT JOIN statements makes sure that the data gathered is synchronized on the ProductID from the Products table and not the InventoryDetail table (if it was from the InventoryDetail, you could get more than one record for the same product and we don't need that in this particular case). This SELECT statement would return something like this:

ProductID ProductName             CurrentPriceSold Quantity AmountTotal
--------- ----------------------- ---------------- -------- -----------
1         Panasonic KXP-1180      100.00           4        400.00
2         HP 5P Lazer Printer     300.00           2        600.00
3         NEC Accusync 70 17"     250.00           3        750.00

...       and so on for all the products in the Products table.

Can you see how much more readable this is compared to manually selecting all kinds of things independently from these two table to try to get the same results but in a more complicated and less readable way? that's one of the advantages of the reporting part of SQL. As a second example, let's take this from a different perspective in the business. Let's assume that the boss wants to know how much money he made so far this year and that he wants those results on a monthly basis. Basically we'll need the same kind of information to give him those results, but we'll swap the Products table with the InvoiceHeader table since that table has the invoice dates that we can work with to give him the monthly results. Let's see how we can give him just that. The SQL Statement will look like this:

   SELECT MONTH(InvoiceHeader.InvoiceDate) AS MonthNumber,
          COUNT(InvoiceNumber) AS InvoiceCount,
          SUM(InvoiceHeader.GrandTotal) AS InvoiceAmounts
     FROM InvoiceHeader
LEFT JOIN (InvoiceDetails) ON (Invoiceheader.InvoiceNumber =InvoiceDetails.InvoiceNumber)
    WHERE InvoiceHeader.InvoiceDate >= '2005-01-01' AND InvoiceHeader.InvoiceDate <= '2005-12-31'
 GROUP BY MonthNumber
 ORDER BY MonthNumber;

This particular query return no physical records from any of the tables it uses, it just brings back results. Typically, a boss doesn't care if he sold a NEC 17" monitor, he'll want to know how much money it gave him instead. This example would return something like:

MonthNumber InvoiceCount InvoiceAmounts
----------- ------------ --------------
1           59           2439.43
2           34           1834.22
3           58           2308.43
4           78           4898.32
5           120          6421.15
6           211          11243.24
7           377          15234.42
8           105          5734.52
9           77           4968.76
10          56           3452.42

And there you have it, this is exactly what the boss asked for. Now this might not seem very useful just looking at numbers. However, to those that want this, one of the crucial information you can extract from this report is that the highest selling months are June (6) and July (7). This can help them make sure they buy enough products to supply the higher demand they can expect this coming year in those months. Now how useful is this report I ask you? And basically that's what reporting is all about. If a report you are asked to create doesn't seem to return any intelligent information to you, or to the one that asked you for this report, it's not worth doing, period.

This brings us to the other question to ask yourself, that question is: "How useful is this report to the one that asked for it." A business manager, an accountant, an inventory manager and a sales department could all want some kind of information based on the inventory and invoices. However, they will typically want that information presented to them in a very different way that is useful to them alone. The first report we did in this section on the products would typically be useful for the Inventory manager. In this last example, well take that first query, and modify it a bit so that it will return, for example, all the sales by category. This is another often asked for report. And as you'll see here, we will need to include a 3rd table in the query to get the name of the category and he Products table will just return how many different products they have in the given category. Here's the SQL Statement:

   SELECT Categories.CategoryID            AS Category,
          Category.CategoryDescription     AS CategoryName,
          COUNT(Products.ProductID)        AS ProductCount,
          SUM(InvoiceDetails.QuantitySold) AS Quantity,
          SUM(InvoiceDetails.LineTotal)    AS AmountTotal
     FROM Products
LEFT JOIN (Products)       ON (Categories.CategoryID=Products.CategoryID)
LEFT JOIN (InvoiceDetails) ON (Products.ProductID=InvoiceDetails.ProductID)
 GROUP BY Categories.CategoryID
 ORDER BY Categories.CategoryID;

It's as simple as that, we selected the fields and functions we needed from the different tables (Categories, Products and InvoiceDetails) created the LEFT JOINs we needed and the report is ready. Here's a typical output from this statement:

Category CategoryName       ProductCount Quantities AmountTotal
-------- ------------------ ------------ ---------- -------------
1        Monitors           121          59         2439.43
2        Printers           100          45         1834.22
3        Scanners           32           132        2308.43
4        Mices              58           564        4898.32
5        Hard Drives        101          254        6421.15

As you can see, it's all about taking the time to sit down and ask yourself what you or the one that needs the report really wants to know and how you need to present it so that you/he/she gets the exact answer they are looking for. This is in the case of a business. A lot of you might have your own forums for example and you could play with the tables of your forums to get specific information from them too like the average number of posts per month you get and other useful information you might need to know when managing a forum.

Reporting queries do have their limits however. In some very complex cases you might not be able to get your answer from one single SQL statement alone. Therefore, in these situations you'll need a tool that helps you get temporary results that you can work with to finish the reporting task completely.

ENTER THE TEMPORARY TABLES:

SQL does provide a means of temporarily saving a subset of records when needed in order to be able to use these temporary results to complete a reporting task. MySQL differs from other databases in that it doesn't support the SELECT INTO TABLE construct. Instead you can use an INSERT INTO Table construct to get the job done. The idea is that you would create a temporary table (designed to be used then dropped) from which you can execute another SELECT statement that will finish the job you started. As such, this technique will create the table, put the information that your first SELECT query will get into it, and then, in a second SELECT statement you would get information from that temporary table, JOIN it into other tables and get the final results you were hoping to get in the first place.

The example I'll use here could have probably been solved by a single SELECT statement. However, for the sake of clarity and your understanding, it will do the job quite well. Let say that you wanted to know how many new customers you had each month of this year. Let's also assume you wanted to know how many invoices and their totals that they purchased as well as the number of items they purchased for that month. Finally let's assume you want that report broken down by month. This typically involves two steps. The first step is to collect the data will need to work with. We'll put that information into a temporary table called CustomerData Once we have that, we'll use a 2nd query to report on the temporary data and break it down by month. Here's the query to gather the data into the temporary table.

INSERT INTO CustomerData
     SELECT Customers.CustomerID             AS Customer,
            Customers.CustomerSince          AS CustomerDate,
            MONTH(Customers.CustomerSince)   AS CustomerMonth,
            InvoiceHeader.InvoiceDate        AS DateOfInvoice,
            MONTH(InvoiceHeader.InvoiceDate) AS InvoiceMonth,
            SUM(InvoiceDetails.QuantitySold) AS Quantity,
            SUM(InvoiceDetails.LineTotal)    AS AmountTotal
       FROM Products
  LEFT JOIN (InvoiceHeader)  ON (Costumers.CustomerID=InvoiceHeader.CustomerID)
  LEFT JOIN (InvoiceDetails) ON (InvoiceHeader.InvoiceNumber=InvoiceDetails.InvoiceNumber)
      WHERE Customers.CustomerSince >= '2005-01-01'
        AND Customers.CustomerID = InvoiceHeader.CustomerID
        AND InvoiceHeader.InvoiceDate >= '2005-01-01'
        AND InvoiceMonth = CustomerMonth
   GROUP BY Customers.CustomerID
   ORDER BY Customers.CustomerID;

This gives a table with 7 columns that have the temporary results in them. Once we have that in the temporary table, we simply issue a 2nd SQL query based on those temporary results. here's what that might look like:

  SELECT CustomerMonth,
         COUNT(CustomerMonth) AS NewCustomers,
         COUNT(DateOfInvoice) AS InvoiceCount,
         SUM(Quantity)        AS ItemCount,
         SUM(AmountTotal)     AS TotalAmount
    FROM CustomerData
GROUP BY CustomerMonth
ORDER BY CustomerMonth;

As you can see, in very complex situations, this use of temporary table really help keep things into perspective and keep the goal of the report clear. This example would give back a report that could look like this:

CustomerMonth NewCustomers InvoiceCount ItemCount InvoiceAmounts
------------- ------------ ------------ --------- --------------
1             23           59           121       2439.43
2             34           56           97        1834.22
3             58           87           134       2308.43
4             78           128          231       4898.32
5             120          185          335       6421.15
6             211          465          684       11243.24
7             377          624          734       15234.42
8             105          160          342       5734.52
9             77           149          522       4968.76
10            56           134          316       3452.42

This report would show again that June and July are he hot sellers, however, with the added information, we can now deduct that since the ItemCount is closer to the InvoiceCount in July, that they have been buying more of the same thing during those months and bought a more diversified list of items in the remainder of the year. After knowing this they could compare that against the inventory history to make sure they are right in their assumption (which, in most cases, would prove to be right). It's important to remember that the more complex a query gets, the harder it gets to follow when it does not return the required information. Therefore, extra care needs to be invested when building the more complex query as debugging it later will prove a bigger headache than needed. Note that if things get more complex, there is nothing to stop you from breaking the reports into more than one temporary table as you need it. The important thing is to keep the reporting queries as clear as they have to be to be maintainable. This way, when situations occur, you'll be better prepared for the process of following what's going on and knowing where the situation is more likely to occur.

THE OFFICIAL FINAL WORD:

And there you have it. We now conclude the 4th and final part of the database series. In these 4 parts, I believe we covered alot of ground as far as database design and management is concerned. I definitaly hope it is useful to your database projects whatever they may be. As I mentionned before, this series covered the MySQL implementation of the SQL syntax. When you go to other databases, such as Oracle, SQL Server and PostGres You'll notice that alot of what you learned here will definitaly serve you well in these other databases too.

As always, I've tried my best to be clear, concise, to the point as much as could. However, some of you might have questions about what you've learned in this series as perhaps I could have written certain parts differenly and make them even easier to understand. Fell absolutely free to send me comments, ideas and suggestions about this series, or any other tutorial I've written in QB Express so far. If you have specific questions, feel free to email me those questions so I can answer them for you to make sure you understand everything that I tried teaching in this (and other) series. Until I write again, happy learning, designing and coding.

MystikShadows
Stéphane Richard
srichard@adaworld.com

Download a copy of this tutorial.

Game	Votes	Percent	Graph
ArKade	0	0%
Battle Pong	3	6.5%
Bounce	1	2.2%
The Griffon Legend	19	41.3%
Poxie	7	15.2%
The Quest For Opa Opa	3	2.2%
Red Jumpy Ball	1	2.2%
Rambo vs. Kitty Cat	3	6.5%
Sokoban FB	0	0%
Other	9	19.6%
46 Total Votes

QB Express

Issue #15 ~ November 3, 2005

In This Issue

From The Editor's Desk

Written by Pete

Submit To QB Express

Letters

Letter From MystikShadows

Letter From Lachie Dazdarian

Letter From Seb McClouth

Letters from mennonite

Express Poll

What is your favorite finished FB game?

News Briefs

QB Site News

Project News

Competition News

Other News

Gallery

Written by Pete

Cadisman

Searching For The UnknownMADMIX GAME by Enrique Huerta, 2000

Written by Lachie Dazdarian

Introduction

About MADMIX GAME

Get MADMIX GAME

Game Production

Written by Matt2Jones

Logos

Title Screen:

The Game

The NSDP pun:

The gay-ass industry jargon:

Qbinux - Revisited, Part Deux

Written by Seb McClouth

Review of The Griffon Legend by syn9

Written by Lachie Dazdarian

Graphics

Sound/Music

Gameplay

Story

Replay value

Challenge

Fun factor

Total Score

Pirates of QB (Starting the QBasic GUI Community)

Written by Rocket Boy

mennonite's last qbe article (huzzah)

Written by mennonite

Some writing about writing (for the Programmer (and anyone else too))

Written by urger (Peter E. Lenz)

Monthly Awards

Written by Pete

Site of the Month

Programmer of the Month

Comics

By Rattrapmax6 and Matt2Jones

Graphical User Interfaces - A Complete StudyPart 1 - GUI Design

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

WHERE DOES IT ALL START:

HOW TO BEGIN THE GUI DESIGN:

MY OWN ANSWERS TO THESE QUESTIONS:

THE QUESTIONS ARE ANSWERED, NOW WHAT:

BREAKING DOWN THE GUI ELEMENTS:

ERGONOS TOOLS AND UTILITIES:

ERGONOS STANDARD DIALOGS:

IN CONCLUSION:

Graphical User Interfaces - A Complete StudyPart 2 - GUI Details and Resources

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

GUI DESIGN ESSENTIALS:

USER INTERACTION EVENTS:

ERGONOS GUI COMPONENTS:

ERGONOS ENGINES:

PART TWO NOW CONCLUDED:

Group A.I.

Written by Jonathan Wallace

C++ For the Basic Programmer: Part 2

Written by The Awakened

Searching For The Unknown
MADMIX GAME by Enrique Huerta, 2000

Graphical User Interfaces - A Complete Study
Part 1 - GUI Design

Graphical User Interfaces - A Complete Study
Part 2 - GUI Details and Resources

Database Design - A Complete Study
Part 4 - Database Reporting