1) Announcing LB Printing for
Dummies
Liberty Basic is develeopped by Carl Gundel Original Newsletter compiled by Alyce Watson and Brosco Translation to HTML: Raymond Roumeas
1) Announcing LB Printing for
DummiesMy rate for publishing newsletters has slowed down a bit. The reason for this is my business is growing and I currently have a contract that keeps me out of town 2 or 3 days a week. This contract will continue until Christmas - and so I am spending more time away from my PC than I like. Maybe when I can afford a laptop PC I will be able to work on the newsletters and LB programming while I'm 'on the road'.
In the meantime, Alyce and I are filling the void with another in the ".... for Dummies" series. This time its - LB Printing for Dummies
Be forwarned - this document is not for beginners - you will need to have experience with API calls - and using a Device Context. I would recommend that you review Newsletter #15 (GDI Programming) before you start on this guide.
2) Understanding Windows
ProgrammingThis is a strange sort of article to write for the LB newsletter, because it doesn't contain much about Liberty Basic. LB shields us from needing to know all the technical details of programming most of the stuff required by Windows. For example, the simple program that writes "Hello World" to the LB #main window requires around 20 API calls - yet we can achieve it by:
'Simple LB program print "Hello World" end
If you write several messages to the #main Window - you need to use the Horizontal and Vertical Scroll bars to scroll through your messages - this adds even more API calls. Then when you define another window with controls - there's even more API calls. A typical program with a couple of windows - several Controls, etc may require a hundred or two API calls - but LB does it all for us with nice, simple Basic statements.
But I find that I understand a language better (and write better code) if I understand the way the language achieves things for me. So with that in mind - I will try to show you how LB and Windows achieve the magic for us.
When you execute a Windows program, it is loaded into memory (RAM) and Windows locates the entry point to the program. All Win programs must have an entry point called "WinMain". This section of the code performs any initialisation required by the program and draws the first or main window. It then passes control back to Windows and says "let me know when there is an action for me to process". At the time you defined your main window - you also specified a section of code that is to be activated when an event occurs. An Event is any user action, such as, moving the mouse, clicking the mouse, using the keyboard, etc.
If you are familiar with DOS programming - this is a very different concept. In DOS - you would draw your window - then keep testing the keyboard and mouse to see if the user has done anything. This is a very important difference. The reason that Windows does things this way is so that it can implement multitasking. When you pass control back to Windows - if there are no events for your program to handle - it checks to see if other programs have events to be processed. Another reason is that when multiple programs are running, they must share most of the resources available, keyboard, mouse, RAM, Disk, screen, etc. With Windows, you cannot access any of these resources directly - you can only access them via API calls (or with LB - via LB commands that construct the API calls for us). Windows is thus able to keep track of the resources your program is using - and ensures that no other program will cause conflicts.
Windows informs your program of events by sending codes to your program. Your program then analyses these codes to determine if you should take some action. If you don't need to take an action - you send the codes back to Windows to take a default action.
For example - if a user clicks on the System 'Close' option, your program is informed. The program can take some action - like verifying with the user that he really intended to do that - or you could just let Windows take the default action - which is to close the window.
By following this concept - your windows program only needs to have code for actions that are important to the program - and can ignore all others. For example, if the user moves the mouse to an 'empty' part of the window and clicks it - even though Windows informs you that this has happened - you can just ignore it. Or - if you want - you could send the user a message saying:
"Clicking here doesn't do anything!"
I have included a program written in POW! ( a language very similar to Pascal). I have both the EXE and source code included.
To write this program in LB would probably have taken 20 or 30 lines of code - but you will see that in POW it takes me hundreds of lines of code and about 30 API calls. If you are familiar with Pascal or C programming languages, you should get a rough idea of what's going on. But the objective of this exercise is just to demonstrate the work done in the background by Liberty Basic.
Run the program 'MSGLOOP.EXE'. Two windows will be displayed. The one on the left shows a log of the messages received by the program. The window on the right has a few controls. Try clicking the Buttons, using the scroll bar, resizing the window, moving and clicking the mouse, etc. Many of the messages generated will be displayed on the log. Note: not all the messages are logged - I have just logged the main ones that are handled by the program - there are many more that I have ignored.
Comments, requests or corrections: Hit 'REPLY' now!