Debugging And The Message Queue In The Initial Programming Language

The Message Queue

Automatically generated message handlers
IPL handles the Windows message queue in a way that I believe is unique.

It compromises flexibility and completeness for ease of use, Windows sends many messages to IPL that are processed automatically and others that IPL simply decides to safely ignore.

For example does someone learning to program want to be able to process the message WM_POWERBROADCAST and decide to do something because the power is about to go off?

Sections

A C** error message The most important Windows Messages are automatically handled and directed to the Sections, Paint, Keyboard, Timer and Mouse and the relevant pre-defined function.

To handle a Mouse Message such as WM_MOUSEMOVE, all you do is change to the Mouse Section and write your code in the pre-created function iplOnMove().

This bit of code changes the direction of a Pacman type character automatically moving left and right and up and down within a defined area.

"Two magic" iplScanCode and iplChar are populated with the key pressed and the character that the key represents.

Whenever the screen needs drawing WM_PAINT, the code in the Paint Section is called so this section should be capable of redrawing the whole screen.

Windows can generate hundreds of different messages, most of these are automatically processed with a safe behaviour and then discarded, this is necessary to support a simple to use language.

For example you can't access messages such as WM_SIZE (window size changed), this seemed a reasonable compromise given that it allowed for an easy to get started with language.


Break Points, Single Step And Profiling

A C** error message The Initial Programming Language supports breakpoints and single stepping, as well as a limited amount of profiling.

Breakpoints allow you to stop the program and examine the variables and then carry on.

Single Stepping means that once a break point is hit you can run just the next statement.

Profiling tells you how much time is spent in each part of the code. Of course this is tricky and is only indicative, but if you move onto a more complex project the idea that things do take time is critical.

In professional programming there has been a trend to using bought in components, which means that they can usually do more than you need, the downside to this is that they can be too slow to use!

As modern PCs are so fast it can be hard to time simple events and the fact that Windows is a multitasking OS which starts and stops your program.