Posted by dcosta on 26/02/2020 23:41:49:
Hello John,
"add this to UserInterface.h
int ButtonStateMachine (bool incrementButtonPressed, bool decrementButtonPressed) ";
Although I have professionally been a programmer / analyst for almost three decades, not having programmed in 'C', I am not sure where in the UserInterface.h file should I insert the line.
Could you do me a favor and tell me where that line should be inserted?
Thanks in advance
Dias Costa
Hi Dias,
Though not into this particular project I am an ex C/C++ programmer.
Looking at userinterface.h I found a short file, starting with a comment section containing licence blurb. The action starts at line 27 :
#ifndef __USERINTERFACE_H
#define __USERINTERFACE_H
#include "ControlPanel.h"
#include "Core.h"
#include "Tables.h"
typedef struct MESSAGE
{
Uint16 message[8];
Uint16 displayTime;
const MESSAGE *next;
} MESSAGE;
class UserInterface
{
The new line can be inserted almost anywhere apart from inside any curly brackets!
I'd put it at the top just before the typedef, roughly line 33 thus
#ifndef __USERINTERFACE_H
#define __USERINTERFACE_H
#include "ControlPanel.h"
#include "Core.h"
#include "Tables.h"
int ButtonStateMachine (bool incrementButtonPressed, bool decrementButtonPressed);
typedef struct MESSAGE
{
…
H files typically contain definitions shared by a number of source files. In this case
int ButtonStateMachine (bool incrementButtonPressed, bool decrementButtonPressed);
means: 'A function called ButtonStateMachine takes two boolean arguments and returns an integer result.'
Boring explanation, if anyone cares:
The function is defined fully somewhere else in a code tree consisting of several source files, and the statement, it's signature, is a promise to the compiler that the full definition of the function will be made available later. So a project consisting of three source files, say A, B and D, will compile A even if it calls a function in D that doesn't exist yet. When the compiler hits an unresolved but explained reference, it leaves a gap in the code ready for the link phase, which is where A+B+C get glued together with any operating system and library calls. The linker, which can see everything, fills any gaps left by the compiler and completes the working whole. It's only an error when the linker can't fill the gaps.
Clear as mud? It's a mechanism allowing programmers to separate code into manageable blocks rather than one giant source file, and then assemble the bits into the whole later. It also allows code to be shared between different projects.
Dave
Edited By SillyOldDuffer on 27/02/2020 11:19:57